[FFmpeg-devel] [PATCH] mov: Remove ancient heuristic hack

[Derek Buitenhuis]

On 8/24/2016 6:50 PM, Carl Eugen Hoyos wrote:
>> This breaks files with legitimate single-entry edit lists,
>> and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
>> has no link to any known sample in its commit message, nor
> 
> I suspect the commit message links to this sample:
> http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue910/

Sample is good to have, but it's unclear  to me what it was
meant to actually fix...

> This reminds me that we should try to find the roundup mailing
> list archives, I don't think there is an online copy anymore;-(

[...]

>> does it actually fix the problem properly, but instead has
>> a one-off heuristic to try and "fix" them at the expense
>> of breaking legitimate files.
> 
> Please remove the personal aspects from your commit message.

I will remove this part.

>> Example file:
>>     http://chromashift.org/samples/delay_problem.mp4
>>
>> Having the DTS delay output on the first packet itself
>> is important for things like cutting files.
>>
>> The behavioral change can be seen with:
>>     $ ffprobe -show_packets delay_problem.mp4
> 
> Could you explain in a less technical way (for me to understand)
> what is wrong with FFmpeg and this file currently?

The DTS of the first packet should be -36 due to the edit list
in the file, but the heuristic erroneously removes it and
sets it to AV_NOPTS_VALUE (the effect in ffprobe is that the first
packet is just entirely missing the DTS field. Negative DTS are
normal in MP4 files and can reflect, for example, decoding delay
due to frame reordering.

Also for example, if you do:
    $ ffprobe -ignore_editlist 1 -show_packets delay_problem.mp4

You'll see that if the edit list is not applied, the DTS is 0,
and the PTS is 36. It follows that shifting everything backwards
by 36, which is how we currently handle edit lists, should end
up with a DTS of -36.

Cheers,
- Derek