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

[Sasi Inguva]

I don't know if the patch can be made more generic to work for all
demuxers, because this patch requires that PTS of all packets be available
in the header.  The other route is to make it very specific to codecs with
B-frames.

On Tue, Nov 14, 2017 at 12:40 PM, Derek Buitenhuis <
derek.buitenhuis at gmail.com> wrote:

> 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.
>
> I can make it specific to only H264 / H265.


> > 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...
>
It is true that the patch will fail to compute the correct delay in lots of
cases. However the consequence of wrongly computing the has_b_frames is
pretty benign. It only increases the buffer size held for PTS  reordering.
I can put a max-value check on the computed video_delay here. So in my
opinion, we won't see fatal regressions where a file is not able to be
decoded / played.


>
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>