Can I update the scan type by ffmpeg? I have a video, which was recorded by kurento.  But the video can't replay. after I checked it,  I think the reason is the scan type is incorrect.

The work video,

Tony-MacBook-Pro:ios tony$ ffmpeg -i good.webm
ffmpeg version 3.4.1 Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.39.2)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.4.1_2 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --disable-jack --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, matroska,webm, from 'good.webm':
  Metadata:
    encoder         : GStreamer matroskamux version 1.8.1.1
    creation_time   : 2018-06-29T17:15:35.000000Z
  Duration: 00:00:57.52, start: 0.000000, bitrate: 438 kb/s
    Stream #0:0(eng): Video: vp8, yuv420p(progressive), 480x640, SAR 1:1 DAR 3:4, 1k tbr, 1k tbn, 1k tbc (default)
    Metadata:
      title           : Video
    Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      title           : Audio


The bad video,

Tony-MacBook-Pro:ios tony$ ffmpeg -i bad.webm
ffmpeg version 3.4.1 Copyright (c) 2000-2017 the FFmpeg developers
  built with Apple LLVM version 9.0.0 (clang-900.0.39.2)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.4.1_2 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --disable-jack --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
Input #0, matroska,webm, from 'bad.webm':
  Metadata:
    encoder         : GStreamer matroskamux version 1.8.1.1
    creation_time   : 2018-06-29T13:52:20.000000Z
  Duration: 00:00:35.19, start: 0.000000, bitrate: 367 kb/s
    Stream #0:0(eng): Video: vp8, yuv420p, 480x640, SAR 1:1 DAR 3:4, 1k tbr, 1k tbn, 1k tbc (default)
    Metadata:
      title           : Video
    Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      title           : Audio 


I compared both, the only difference is the 1st one has yuv420p(progressive), the 2nd one has yuv420p; so I guess that's the root cause, and want to change the scan type to try.

bad file: https://www.dropbox.com/s/t07pfe69a78h1tg/bad.webm?dl=0
good file: https://www.dropbox.com/s/uivgb1trobhrg5n/good.webm?dl=0
The issue isn't the scan type but the timestamps for the video stream.

Run

ffmpeg -i bad.webm -c copy -an badv.nut


and then

ffmpeg -i badv.nut -i bad.webm -c copy -map 0:v -map 1:a new.,webm




The video timestamps start at some large non-zero number but the audio TS start at zero. That throws stream queueing out-of-whack since the sync relies on the stream with earliest start time within the file. The two step method works around that by isolating the video first into its own file.