[FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.
derek.buitenhuis at gmail.com
Wed Nov 15 01:23:08 EET 2017
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
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
>> 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.
Does anyone else have an opinion™ on this? I guess it's "OK enough" if
restricted by codec...? :V
More information about the ffmpeg-devel