[x265] Bug report: incorrect computation of sps_max_dec_pic_buffering_minus1

[Olivier Lapicque]

"(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:x265-devel-bounces at videolan.org] 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 <olapicque at nvidia.com<mailto:olapicque at nvidia.com>> 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.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130923/68f528fd/attachment-0001.html>