<div dir="ltr">Hi Kalyan,<div>If this is the case, then everything is fine.</div><div>Best,</div><div>Alex.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 12, 2018 at 2:28 AM, Kalyan Goswami <span dir="ltr"><<a href="mailto:kalyan@multicorewareinc.com" target="_blank">kalyan@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Alex, </div><div><br></div><div>I think there is some misunderstanding of this email thread. I have checked the patch along with Ashok and Aruna, and my understanding is given below as a diagram. In this patch, we are introducing a small offset (5%) which aims the buffer fullness to be less the target by this offset. Since VBV is a probabilistic algorithm, this offset (depend upon the complexity of the video) provides little more confidence about the overshoot of the buffer. </div><div><br></div><div>In addition to that, this offset is always negative (in terms of buffer fullness). Hence, it should not break your existing system. </div><div>Please let us know if we are missing something. </div><div><br></div><div><div><img src="cid:ii_jibavu772_163f2a9e9b71f997" width="496" height="146"><br></div>Thanks, </div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-4547903573417672120gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span></span><span></span>Kalyan Goswami, PhD</div><div dir="ltr"><span style="font-size:12.8px">Video Architect @ MulticoreWare</span></div><div dir="ltr"><div><a href="http://www.multicorewareinc.com/" target="_blank">http:</a><a href="http://www.multicorewareinc.com/" style="font-size:12.8px" target="_blank">//www.multicorewareinc.<wbr>com</a></div><div><span style="font-size:12.8px">+91 9884989331</span><br></div><div></div></div></div></div></div></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Mon, Jun 11, 2018 at 10:56 PM, Alex Giladi <span dir="ltr"><<a href="mailto:alex.giladi@gmail.com" target="_blank">alex.giladi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This may still break HRD compliance -- imagine you have a large amount of chunks (hundreds or thousands per movie) which you encode in parallel. <div>Under VBV-based (VBV or VBV+CRF) rate control you try running as close to the buffer capacity as you can. If uncoordinated overshoot of e.g. 4% in buffer fulness occurs sufficiently frequently, chunks towards the end may overflow as we developed a drift between the real CPB fulness and the CPB fulness assumed by x265 encoding a chunk.</div><div><br></div><div>Hence this patch breaks HRD compatibility for parallel encoding of any sufficiently complex long-form content. To make things more interesting, this breakage is not deterministic.</div><div><br></div><div>You can allow fullness which is less than vbv-end. This would mean that towards the end of the movie you may be under-utilizing the CPB, but you will not generate incompliant streams.</div></div><div class="m_-4547903573417672120HOEnZb"><div class="m_-4547903573417672120h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 11, 2018 at 1:24 AM, Aruna Matheswaran <span dir="ltr"><<a href="mailto:aruna@multicorewareinc.com" target="_blank">aruna@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jun 11, 2018 at 3:34 AM, Alex Giladi <span dir="ltr"><<a href="mailto:alex.giladi@gmail.com" target="_blank">alex.giladi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Does this "5% tolerance" imply that CPB fullness as defined by vbv-end can be exceeded by 5%?</div></blockquote><div><br></div></span><div>yes, the CPB fullness can vary by +/- 5 % from the value defined by vbv-end. </div><div><div class="m_-4547903573417672120m_-3164218855434183655h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-4547903573417672120m_-3164218855434183655m_8060553625789790075gmail-h5">On Fri, Jun 8, 2018 at 6:39 AM, <span dir="ltr"><<a href="mailto:aruna@multicorewareinc.com" target="_blank">aruna@multicorewareinc.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_-4547903573417672120m_-3164218855434183655m_8060553625789790075gmail-h5"># HG changeset patch<br>
# User Aruna Matheswaran <<a href="mailto:aruna@multicorewareinc.com" target="_blank">aruna@multicorewareinc.com</a>><br>
# Date 1523005500 -19800<br>
# Fri Apr 06 14:35:00 2018 +0530<br>
# Node ID ed853c4af6710a991d0cdf4bf68e00<wbr>fe32edaacb<br>
# Parent 182914e1d201395d152e310db7f5cf<wbr>29ab3c787e<br>
Add vbv-end tolerance check<br>
<br>
This will attempt to keep the desired fraction of the target buffer ( specified<br>
by vbv-end ) empty within a defined error margin of 5%.<br>
<br>
diff -r 182914e1d201 -r ed853c4af671 source/encoder/ratecontrol.cpp<br>
--- a/source/encoder/ratecontrol.c<wbr>pp Wed Mar 14 12:30:28 2018 +0530<br>
+++ b/source/encoder/ratecontrol.c<wbr>pp Fri Apr 06 14:35:00 2018 +0530<br>
@@ -1282,6 +1282,12 @@<br>
m_predictedBits = m_totalBits;<br>
updateVbvPlan(enc);<br>
rce->bufferFill = m_bufferFill;<br>
+ rce->vbvEndAdj = false;<br>
+ if (m_param->vbvBufferEnd && rce->encodeOrder >= m_param->vbvEndFrameAdjust * m_param->totalFrames)<br>
+ {<br>
+ rce->vbvEndAdj = true;<br>
+ rce->targetFill = 0;<br>
+ }<br>
<br>
int mincr = enc->m_vps.ptl.minCrForLevel;<br>
/* Profiles above Main10 don't require maxAU size check, so just set the maximum to a large value. */<br>
@@ -2173,12 +2179,12 @@<br>
curBits = predictSize(&m_pred[predType], frameQ[type], (double)satd);<br>
bufferFillCur -= curBits;<br>
}<br>
- if (m_param->vbvBufferEnd && rce->encodeOrder >= m_param->vbvEndFrameAdjust * m_param->totalFrames)<br>
+ if (rce->vbvEndAdj)<br>
{<br>
bool loopBreak = false;<br>
double bufferDiff = m_param->vbvBufferEnd - (m_bufferFill / m_bufferSize);<br>
- targetFill = m_bufferFill + m_bufferSize * (bufferDiff / (m_param->totalFrames - rce->encodeOrder));<br>
- if (bufferFillCur < targetFill)<br>
+ rce->targetFill = m_bufferFill + m_bufferSize * (bufferDiff / (m_param->totalFrames - rce->encodeOrder));<br>
+ if (bufferFillCur < rce->targetFill)<br>
{<br>
q *= 1.01;<br>
loopTerminate |= 1;<br>
@@ -2421,6 +2427,7 @@<br>
double rcTol = bufferLeftPlanned / m_param->frameNumThreads * m_rateTolerance;<br>
int32_t encodedBitsSoFar = 0;<br>
double accFrameBits = predictRowsSizeSum(curFrame, rce, qpVbv, encodedBitsSoFar);<br>
+ double vbvEndBias = 0.95;<br>
<br>
/* * Don't increase the row QPs until a sufficent amount of the bits of<br>
* the frame have been processed, in case a flat area at the top of the<br>
@@ -2442,7 +2449,8 @@<br>
while (qpVbv < qpMax<br>
&& (((accFrameBits > rce->frameSizePlanned + rcTol) ||<br>
(rce->bufferFill - accFrameBits < bufferLeftPlanned * 0.5) ||<br>
- (accFrameBits > rce->frameSizePlanned && qpVbv < rce->qpNoVbv))<br>
+ (accFrameBits > rce->frameSizePlanned && qpVbv < rce->qpNoVbv) ||<br>
+ (rce->vbvEndAdj && ((rce->bufferFill - accFrameBits) < (rce->targetFill * vbvEndBias))))<br>
&& (!m_param->rc.bStrictCbr ? 1 : abrOvershoot > 0.1)))<br>
{<br>
qpVbv += stepSize;<br>
@@ -2453,7 +2461,8 @@<br>
while (qpVbv > qpMin<br>
&& (qpVbv > curEncData.m_rowStat[0].rowQp || m_singleFrameVbv)<br>
&& (((accFrameBits < rce->frameSizePlanned * 0.8f && qpVbv <= prevRowQp)<br>
- || accFrameBits < (rce->bufferFill - m_bufferSize + m_bufferRate) * 1.1)<br>
+ || accFrameBits < (rce->bufferFill - m_bufferSize + m_bufferRate) * 1.1<br>
+ || (rce->vbvEndAdj && ((rce->bufferFill - accFrameBits) > (rce->targetFill * vbvEndBias))))<br>
&& (!m_param->rc.bStrictCbr ? 1 : abrOvershoot < 0)))<br>
{<br>
qpVbv -= stepSize;<br>
diff -r 182914e1d201 -r ed853c4af671 source/encoder/ratecontrol.h<br>
--- a/source/encoder/ratecontrol.h<wbr> Wed Mar 14 12:30:28 2018 +0530<br>
+++ b/source/encoder/ratecontrol.h<wbr> Fri Apr 06 14:35:00 2018 +0530<br>
@@ -82,6 +82,8 @@<br>
double rowCplxrSum;<br>
double qpNoVbv;<br>
double bufferFill;<br>
+ double targetFill;<br>
+ bool vbvEndAdj;<br>
double frameDuration;<br>
double clippedDuration;<br>
double frameSizeEstimated; /* hold frameSize, updated from cu level vbv rc */<br>
<br></div></div>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/l<wbr>istinfo/x265-devel</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/l<wbr>istinfo/x265-devel</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/l<wbr>istinfo/x265-devel</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org" target="_blank">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/l<wbr>istinfo/x265-devel</a><br>
<br></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
<br></blockquote></div><br></div>