"(param->bframes+2)-1" seems correct for 1-backward and 1 forward reference (but seems like it would be too low for more than 2 refs). The exact condition that was violated in the bitstream I saw is the following: NumNegativePics(4) + NumPositivePics(1) + num_long_term_sps(0) + num_long_term_pics(0) > max_dec_pic_buffering_minus1(3)+1
I'll get the exact cmdline parameters to reproduce this, but I was told that this problem occurs any time B-frames are enabled. Olivier From: x265-devel [mailto:[email protected]] On Behalf Of Steve Borho Sent: Monday, September 23, 2013 12:10 PM To: Development for x265 Subject: Re: [x265] Bug report: incorrect computation of sps_max_dec_pic_buffering_minus1 On Mon, Sep 23, 2013 at 1:56 PM, Olivier Lapicque <[email protected]<mailto:[email protected]>> wrote: x265 doesn't appear to include reordering delay due to B-frames in sps_max_dec_pic_buffering_minus1 (I believe early builds of x264 had a similar issue) While this is currently not flagged as an error by the HM decoder (HM doesn't enforce the DPB size restriction), it is technically non-compliant (can lead to incorrect output order in a decoder that actually enforces the dpb size limit) Thanks Olivier, Near as I can tell, we're setting this to "(param->bframes + 2) - 1" which seems sane. Can you provide a command line that generates a non-compliant stream? Regards, -- Steve Borho ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
