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

[Sasi Inguva]

restricted the patch to MPEG based codecs. Also, setting the delay only if
it's not set already and capping the max. value to 16.

On Wed, Nov 15, 2017 at 5:55 AM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Tue, Nov 14, 2017 at 03:36:49PM -0800, Thierry Foucu wrote:
> > 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
> > latency.
>
> it could also increase memory requirements substantially
>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>