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

Thierry Foucu tfoucu at gmail.com
Wed Nov 15 01:36:49 EET 2017

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

> On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > 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.
> All PTS may not be available in MP4 either, in the live profile fragmented
> MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> code
> say whether we seek to each fragment and make it available or not. I assume
> you've tested such a case, or can (or know the fragment code)?
> It's feasible to restrict it to codecs, I suppose.
> >> 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.
> The GOP structure should be applicable to most MPEG codecs, I think.
> > 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.
> It's true it's likely benign, but it's not exactly a "fix" either...
> From a user perspective, it's kinda possible to work around it "properly"
> (I use that term loosely here) by decoding enough frames to fill the max
> DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> (or in a user's code if they don't use that function), isn't it? Though,
> I feel that particular fix won't be welcomed with open arms, due to a
> ~16x 'slow down' in probing.
One option i asked on IRC was to use the spec for max DPB when the bitstream
restriction flag was not set.
But people were worry about low latency usage.
Normally, if the  bitstream restriction flag is not set, the DPB should be
set based on the spec, even if there is no B frames.
But in some case, it will be 16 frame and this could increase then the low

> Does anyone else have an opinion™ on this? I guess it's "OK enough" if
> restricted by codec...? :V
> - Derek
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list