[FFmpeg-trac] #5713(ffmpeg:new): Can't Recalculate the Timestamp of Fragmentary Video Streams (was: The timestamp still remaining the same within MKV when all the bytes filled with zeros are removed)

FFmpeg trac at avcodec.org
Tue Sep 27 08:19:10 EEST 2016

#5713: Can't Recalculate the Timestamp of Fragmentary Video Streams
             Reporter:  PureOcean   |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  ffmpeg
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
Changes (by PureOcean):

 * component:  undetermined => ffmpeg


 Okay. I '''finally''' found the root cause.

 FFmpeg can't recalculate only the timestamp of fragmentary video streams.
 Although it's can be resync properly to audio streams. Is it not strange?
 (A more interesting: '''MEncoder''' can recalculate/resync the timestamp
 both of fragmentary video & audio streams).

 '''Steps for Analyze & Re-produce:'''

 ''1) Download to example a fragmentary sample:''

 The Purpose: If the file's timestamp seems as '''00:14:48''', it is need
 resync/recalculate. Because of the file is fragmentary/brokenly.

 ''2) Run (remux only audio stream):''
 FFmpeg -i Random_Seeking_Stream-Sintel_Sample.mkv -vn -async -1

 The Result: New timestamp is '''00:03:48''' which it's properly timecode!
 Incredible, well done FFmpeg (thanks to all who contributed)!

 ''3) Run (remux only video stream):''
 FFmpeg -i Random_Seeking_Stream-Sintel_Sample.mkv -c:v copy -an -vsync -1

 The Result: The only video track's timestamp is still remaining the same
 input file, it can't resynced.

 ''4) Run (remux both of video + audio stream):''
 FFmpeg -i Random_Seeking_Stream-Sintel_Sample.mkv -c:v copy -c:a copy
 -vsync -1 -async -1 not_synced.mkv

 The Result: The output MKV's timecode not changed, still remains same (due
 to can't resynced to video stream). The video now plays with anormal
 speed, because of actually only the audio track is resynced properly.

Ticket URL: <https://trac.ffmpeg.org/ticket/5713#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list