<p dir="ltr">Well, ratecontrol neednt manipulate this object at all, it needs to be handled only in compressFrame.</p>
<div class="gmail_quote">On Jun 29, 2015 10:49 PM, "Steve Borho" <<a href="mailto:steve@borho.org">steve@borho.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/29, Deepthi Nandakumar wrote:<br>
> Should m_startEndOrder be a member of Encoder, rather than ratecontrol,<br>
> since it serializes RcStarts, slice context inits as well as   some CTU row<br>
> encodes?<br>
<br>
it might be an even worse layering violation for rate-control to<br>
directly manipulate an object in the top-level encoder.<br>
<br>
I'm thinking the best option would be to add a new RC method that is<br>
called just before the CTU compress loop. which increments the counter<br>
when RC is in the appropriate mode. Or perhaps just calling<br>
updateStats() early for these modes.<br>
<br>
--<br>
Steve Borho<br>
_______________________________________________<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/listinfo/x265-devel</a><br>
</blockquote></div>