[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

Derek Buitenhuis derek.buitenhuis at gmail.com
Tue Nov 14 22:40:51 EET 2017


On 11/14/2017 8:28 PM, Sasi Inguva wrote:
> For H264 files with no bitstream restriction flag, we aren't able to guess
> the delay correctly. Especially if it's MOV container, because for MOV
> container we just probe the 1st frame and stop in avformat_find_streaminfo .

You do not appear to be restricting this to one specific codec, or even codecs
with B-frames.

> When we are decoding , we increase the has_b_frames value from zero to 1 or
> 2, when we eventually encounter B-frames in H264 decoder, but that is too
> late and we have already dropped 1 or 2 frames. Lot of other fields in
> codecpar are being set from the demuxer like channel_layout, sample_rate
> etc.

I am aware of the intend, however...

The difference between filling those fields in and this patch, is that we can
read those values directly, generally. This is a guess; a heuristic. A heuristic
based on the GOP structure of a single codec. Where we guess where a GOP even
starts. Nor does it seem to take into account non-friendly files, with oddly
ordered and/or invalid timestamps (which it can't, based solely on PTS).

I'm pretty tired of hitting insane edge cases in other types of files due to
hacks added for some other specific set of file, but used for *everything*.
This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep
more out...

- Derek


More information about the ffmpeg-devel mailing list