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

[Michael Niedermayer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171115/3381c18c/attachment.sig>