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

[Carl Eugen Hoyos]

2017-11-15 0:36 GMT+01:00 Thierry Foucu <tfoucu at gmail.com>:
> 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.

I believe this should be done if the user had set -strict 1

Carl Eugen