vps.numReorderPics should be 0 when there's no backward prediction

[Former user]

Currently, zero-delay streams aren't actually marked as zero-delay.

The following "works", though I didn't look for side-effects in the level checker.

#!

diff -r 8c66a97cd442 source/encoder/level.cpp
--- a/source/encoder/level.cpp  Tue Jan 13 21:34:38 2015 +0530
+++ b/source/encoder/level.cpp  Tue Jan 13 18:54:32 2015 -0800
@@ -199,8 +199,8 @@
  * circumstances it will be quite noisy */
 bool enforceLevel(x265_param& param, VPS& vps)
 {
-    vps.numReorderPics = (param.bBPyramid && param.bframes > 1) ? 2 : 1;
-    vps.maxDecPicBuffering = X265_MIN(MAX_NUM_REF, X265_MAX(vps.numReorderPics + 1, (uint32_t)param.maxNumReferences) + vps.numReorderPics);
+    vps.numReorderPics = (param.bBPyramid && param.bframes > 1) ? 2 : !!param.bframes;
+    vps.maxDecPicBuffering = X265_MIN(MAX_NUM_REF, X265_MAX(vps.numReorderPics + 2, (uint32_t)param.maxNumReferences) + vps.numReorderPics);

     /* no level specified by user, just auto-detect from the configuration */
     if (param.levelIdc <= 0)

[Former user]

Also, x265 currently always write sps_max_latency_increase_plus1 as 0 (infinite).

It'd be straightforward and more precise to set that to bframes + 1.

[Steve Borho]

patches sent to our ML for review

[Deepthi Nandakumar]

level: make --tune zero-latency have zero-latency at the decoder (closes #99)

→ <<cset 288fb71ac4a2>>

[Deepthi Nandakumar]

slice: signal sps_max_latency_increase_plus1 more accurately (refs #99)

→ <<cset 998358779845>>