Can't Recalculate the Timestamp of Fragmentary Video Streams

[PureOcean]

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:

​http://ffmpeg.org/pipermail/ffmpeg-user/2016-July/032793.html

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:
​https://mega.nz/#!htBQUDJD!Pr-TkZN5GmyCe99k1RfBkVh7ahp-9npjX74HE36ktfo

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.

Command-line usage:

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.

[PureOcean]

FFmpeg's report file

[Carl Eugen Hoyos]

Replying to PureOcean:

I contacted to Carl Eugen Hoyos. He is reproduced and confirm the issue:

I believe this is a lie.

Reproducing your findings is trivial, I don't know if there is a bug.
Two files, mkv and mov, are provided that contain large areas filled with zeroes (incomplete torrent download). Remuxing the mov sample does not change its size, remuxing the mkv file reduces the size by >70%. The output mkv file plays as good as the input mkv file.

[PureOcean]

I believe this is a lie.

Dear Mr. Hoyos,

My heart's beating so fast. I'm intimately sorry for you, Mr. Hoyos. I sincerely apologize for my previous sentence. Sincerely, I'd like you to know that I never, never intended to lie or on purpose/fraudulent/false representation. I did mistranslated, misinterpreted and misunderstand your sentence, thereby; that is unintentional, innocent misrepresentation. I wish I had died before writing that sentence. I'm deeply grieved that. :'(

I tried to solve this matter so hard, for days without sleeping much. However, I know that this is a very personal issue.

In these premises, how can I request my problem to be analyzed, reproduced and fixed by FFmpeg experts, developers?

I'm so sorry to bother you with this and take up your (and everyone's) time. Could you please delete to this ticket/bug report for good?

Kind Regards,

İlker Tezcan
(from istanbul)

[PureOcean]

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: ​https://mega.nz/#!htBQUDJD!Pr-TkZN5GmyCe99k1RfBkVh7ahp-9npjX74HE36ktfo

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 only_audio-timestamp_can_be_resynced_properly.mkv

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 only_video-timestamp_not_resynced.mkv

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.