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 <mich...@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.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. > > 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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
