[x265] [PATCH] rc: fixes inconsistent output in linux because of RC Lock in CQP/CRF

[Deepthi Nandakumar]

Well, ratecontrol neednt manipulate this object at all, it needs to be
handled only in compressFrame.
On Jun 29, 2015 10:49 PM, "Steve Borho" <steve at borho.org> wrote:

> On 06/29, Deepthi Nandakumar wrote:
> > Should m_startEndOrder be a member of Encoder, rather than ratecontrol,
> > since it serializes RcStarts, slice context inits as well as   some CTU
> row
> > encodes?
>
> it might be an even worse layering violation for rate-control to
> directly manipulate an object in the top-level encoder.
>
> I'm thinking the best option would be to add a new RC method that is
> called just before the CTU compress loop. which increments the counter
> when RC is in the appropriate mode. Or perhaps just calling
> updateStats() early for these modes.
>
> --
> Steve Borho
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150629/7c0d2f5b/attachment.html>