[x265] Bug report: incorrect computation of sps_max_dec_pic_buffering_minus1

[Steve Borho]

On Tue, Sep 24, 2013 at 11:02 AM, Olivier Lapicque <olapicque at nvidia.com>wrote:

> This was the cmdline info used (Though I don’t know which build of x265
> was used):****
>
> ** **
>
> <<** **
>
> *./x265 --input ~/FILES/yuv/720p50_parkrun_ter.yuv --fps 30 --input-res
> 1280x720 --refresh 2 -i 30 --bitrate 5000 -o
> parkrun_ter_720p30fps_5Mbps.hevc*
>
> ** **
>
> Encoding info as printed by x265 is below.****
>
> yuv  [info]: 1280x720 30Hz, frames 0 - 49 of 50****
>
> x265 [info]: detected SIMD architectures SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 ***
> *
>
> x265 [info]: performance primitives: intrinsic****
>
> x265 [info]: Main profile, Level-3.1 (Main tier)****
>
> x265 [info]: WPP streams / pool / frames  : 12 / 8 / 1****
>
> x265 [info]: CU size                      : 64****
>
> x265 [info]: Max RQT depth inter / intra  : 3 / 3****
>
> x265 [info]: ME / range / subpel / merge  : star / 60 / 5 / 5****
>
> x265 [info]: Keyframe min / max           : 30 / 30****
>
> x265 [info]: Rate Control                 : ABR-5000 kbps****
>
> x265 [info]: Lookahead len / *-b* / bAdapt  : 10 / *3* / 1      *[Default
> is max 3 consecutive B-frames, corresponding to “-b 3” option]*****
>
> x265 [info]: tools: rect amp rdo rdoq lft sao sao-lcu sign-hide tskip
> tskip-fast rdoqts ****
>
> x265 [info]: frame I:2      kb/s: 38722.20 PSNR Mean: Y:39.782 U:43.591
> V:44.109****
>
> x265 [info]: frame P:32     kb/s: 5119.59  PSNR Mean: Y:27.178 U:39.095
> V:40.228****
>
> x265 [info]: frame B:16     kb/s: 1147.47  PSNR Mean: Y:26.369 U:38.924
> V:40.048****
>
> x265 [info]: global:        kb/s: 5192.62  PSNR Mean: Y:27.423 U:39.220
> V:40.326****
>
> encoded 50 frames in 115.83s (0.43 fps), 5193.93 kb/s, Global PSNR: 30.511
>

With --b-adapt 1, x265 rarely selects more than one consecutive B frame;
that part of the algorithm has some arbitrary constants adopted from x264
that likely need more tuning.  But that doesn't have much bearing on
whether we're signaling the headers properly.

I can tell by the log output your build is somewhat recent.  I will be
tagging 0.4.1 today and I suggest everyone move up to this tag.  There are
several significant lookahead and rate control fixes on stable since 0.4.
 It would be helpful if you could determine whether the problem still
exists.

Thanks,

--
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130924/cbdf0bf5/attachment.html>