Can't Recalculate the Timestamp of Fragmentary Video Streams
|Reported by:||PureOcean||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
Summary of the bug:
Media Player applications and video-stream-servers stores on user's disk full-size of the video files when non-start playback. It filled many "00" hex codes. Overwrites "00" codes that downloading video and audio data all the more.
Pot Player, etc or Torrent-Stream applications can plays any a video on URL. I jumping randomly scenes in when the video playing. (Or only play it wanted scene). Then I terimante the application. Cache (video) file still remain. Of course, its need fix.
FFmpeg can trim empty/fill-zero bytes (padding? chunks?) from the video which it contain many "00" hex codes. So, the video-size will be reduced as streaming data (without re-encoding). But the output video's timestamp still remain.
While FFmpeg can't fix timestamp, Meteorite (https://sourceforge.net/projects/meteorite/) can fix, even though it don't update since 2011.
I contacted to Carl Eugen Hoyos. He is reproduced and confirm the issue:
How to reproduce:
I'm know, the reproducing very hard (specified). Please don't trouble yourself with it.
I already uploaded the sample. You may download from:
Why I uploaed as ZIP? Because the orginal size is 642 MB but as I was saying, its fulled many "00" codes. Therefore, it compressed down to 37 MB which this is actual size that streaming/downloading.
ffmpeg -i Fill_Zero_Bytes_Can_Trim_But_Timestamp_still_remain.mkv -c copy properly.mkv
ffmpeg version N-80999-gf41e37b
P.S.: I'm sorry, my bad English grammar.
Change History (5)
follow-up: 2 comment:1 by , 5 years ago
|Component:||ffmpeg → undetermined|
|Reproduced by developer:||unset|
|Version:||unspecified → git-master|
comment:3 by , 5 years ago
|Summary:||While remuxing a MKV's filled-zero bytes can trim, the timestamp still remain → The timestamp still remaining the same within MKV when all the bytes filled with zeros are removed|