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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
