2017-11-15 0:36 GMT+01:00 Thierry Foucu <tfo...@gmail.com>: > On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis < > derek.buitenh...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
