[x265] [PATCH] rc: fixes inconsistent output in linux because of RC Lock in CQP/CRF
aarthi at multicorewareinc.com
aarthi at multicorewareinc.com
Mon Jun 29 08:40:49 CEST 2015
# HG changeset patch
# User Aarthi Thirumalai
# Date 1435312791 -19800
# Fri Jun 26 15:29:51 2015 +0530
# Node ID 2dac97717742d6187df7798bdfbd8a9f04e6f446
# Parent f7bbb04e1992a238aee739a0e21777932c1dfa57
rc: fixes inconsistent output in linux because of RC Lock in CQP/CRF
the inconsistency is due to a race hazrd in slice context initializations when 2 Frame Encoders complete
RateControlStart in correct order but slice context initializations in the wrong order in CRF/CQP.
diff -r f7bbb04e1992 -r 2dac97717742 source/encoder/frameencoder.cpp
--- a/source/encoder/frameencoder.cpp Fri Jun 26 10:16:29 2015 +0530
+++ b/source/encoder/frameencoder.cpp Fri Jun 26 15:29:51 2015 +0530
@@ -474,6 +474,19 @@
m_nalList.serialize(NAL_UNIT_PREFIX_SEI, m_bs);
}
+ /* CQP and CRF (without capped VBV) doesn't use mid-frame statistics to
+ * tune RateControl parameters for other frames.
+ * Hence, for these modes, update m_startEndOrder and unlock RC for previous threads waiting in
+ * RateControlEnd here, after the slicecontexts are initialized. For the rest - ABR
+ * and VBV, unlock only after rateControlUpdateStats of this frame is called */
+ if (m_param->rc.rateControlMode != X265_RC_ABR && !m_top->m_rateControl->m_isVbv)
+ {
+ m_top->m_rateControl->m_startEndOrder.incr();
+
+ if (m_rce.encodeOrder < m_param->frameNumThreads - 1)
+ m_top->m_rateControl->m_startEndOrder.incr(); // faked rateControlEnd calls for negative frames
+ }
+
/* Analyze CTU rows, most of the hard work is done here. Frame is
* compressed in a wave-front pattern if WPP is enabled. Row based loop
* filters runs behind the CTU compression and reconstruction */
diff -r f7bbb04e1992 -r 2dac97717742 source/encoder/ratecontrol.cpp
--- a/source/encoder/ratecontrol.cpp Fri Jun 26 10:16:29 2015 +0530
+++ b/source/encoder/ratecontrol.cpp Fri Jun 26 15:29:51 2015 +0530
@@ -1087,18 +1087,6 @@
}
m_framesDone++;
- /* CQP and CRF (without capped VBV) doesn't use mid-frame statistics to
- * tune RateControl parameters for other frames.
- * Hence, for these modes, update m_startEndOrder and unlock RC for previous threads waiting in
- * RateControlEnd here.those modes here. For the rest - ABR
- * and VBV, unlock only after rateControlUpdateStats of this frame is called */
- if (m_param->rc.rateControlMode != X265_RC_ABR && !m_isVbv)
- {
- m_startEndOrder.incr();
-
- if (rce->encodeOrder < m_param->frameNumThreads - 1)
- m_startEndOrder.incr(); // faked rateControlEnd calls for negative frames
- }
return m_qp;
}
More information about the x265-devel
mailing list