[x265] [PATCH] Improve Slices option with check zeroMv

[chen]

Hi Richard,




We don't change default frame-threads to 1 for more compression performance reason, the

slice mostly use for large resolution, it allow encoder couple future frame in parallel, the user

may set frame-threads to 1 for more compression ratio.

In exist method, we made restrict on vertical motion only, most motion in horizon direction, 

compression performance drop is not so much around the slice boundary.



Moreover, the inconsistency is a problem, if output bitstream become different each run, it
difficult to debug and estimate output effect.


If more people interesting Slice than Tile, we may use area lock to keep output deterministic
without limited MV range, it may more balance in speed and compression performance.


Regards,
Chen

At 2025-03-18 14:38:57, "Richard" <ccc7922 at foxmail.com> wrote:

Yes, that fixes the most prominet problem, but there's still compression lost due to the restriction,
you know, a horizontal pan isn't all that rare in the everyday contents.


May I ask what's the extent of the impact of this incorrectness, to the encoding?
If it only causes run to run inconsistency, that's actually not a big problem, it was supposed to be
fixed in the previous commit (eaeeab5 back in Nov 2016), but apparently something changed
along the way broke it again, now it's non-deterministic again even with the restriction.


I suggest default frame-threads to 1 when multiple slices are used. It helps with both deterministic
and compression (because the restriction is not applied).


Original





Hi Richard,




There are parallelism restrict, interpolate can't across slice boundary.

The range [-16,+12] is integer pixel [-4,+3], if MV Y-axis in this range, the interpolate may generate incorrect result.

There have some special point interpolate in Horizontal direction only, but it is less probability to choice as best MV, so just check ZeroMv enough.




Regards

Chen







At 2025-03-17 23:12:32, "Richard" <ccc7922 at foxmail.com> wrote:

Zero MV is only one special case of the problem.


The code of MV restriction calculation:
    tld.analysis.m_sliceMinY = -(int32_t)(rowInSlice * m_param->maxCUSize * 4) + 3 * 4;
    tld.analysis.m_sliceMaxY = (int32_t)((endRowInSlicePlus1 - 1 - row) * (m_param->maxCUSize * 4) - 4 * 4);


The constants will cause MVs to be restricted to >12 or <-16 in slice boundaries.
example:
    minY: -2036, maxY: -16
or
    minY: 12, maxY: 1776
So any MV that has its Y-axis in the range of -16 to 12 will have problem.


Original




From baff7691e9bc4f93bccc85ae78d95ad9ade7a8d0 Mon Sep 17 00:00:00 2001
From: Min Chen <chenm003 at 163.com>
Date: Fri, 14 Mar 2025 22:27:02 -0700
Subject: [PATCH] Improve Slices option with check zeroMv


---
 source/encoder/analysis.cpp | 4 ++--
 source/encoder/motion.cpp   | 8 ++++++++
 2 files changed, 10 insertions(+), 2 deletions(-)


diff --git a/source/encoder/analysis.cpp b/source/encoder/analysis.cpp
index 5475e4800..e3c410e59 100644
--- a/source/encoder/analysis.cpp
+++ b/source/encoder/analysis.cpp
@@ -3166,7 +3166,7 @@ void Analysis::checkMerge2Nx2N_rd0_4(Mode& skip, Mode& merge, const CUGeom& cuGe
     }
     for (uint32_t i = 0; i < numMergeCand; ++i)
     {
-        if (m_bFrameParallel)
+        if (m_bFrameParallel && candMvField[i][0].mv.notZero())
         {
             // Parallel slices bound check
             if (m_param->maxSlices > 1)
@@ -3300,7 +3300,7 @@ void Analysis::checkMerge2Nx2N_rd5_6(Mode& skip, Mode& merge, const CUGeom& cuGe
     }
     for (uint32_t i = 0; i < numMergeCand; i++)
     {
-        if (m_bFrameParallel)
+        if (m_bFrameParallel && candMvField[i][0].mv.notZero())
         {
             // Parallel slices bound check
             if (m_param->maxSlices > 1)
diff --git a/source/encoder/motion.cpp b/source/encoder/motion.cpp
index 58e943652..86f413c3d 100644
--- a/source/encoder/motion.cpp
+++ b/source/encoder/motion.cpp
@@ -1596,6 +1596,14 @@ me_hex2:
     // check mv range for slice bound
     X265_CHECK(((bmv.y >= qmvmin.y) & (bmv.y <= qmvmax.y)), "mv beyond range!");
 
+    // Get a chance to ZeroMv
+    if (bmv.notZero())
+    {
+      int cost = subpelCompare(ref, MV(0, 0), satd) + mvcost(MV(0, 0));
+      if (cost <= bcost)
+        bmv = MV(0, 0);
+    }
+
     x265_emms();
     outQMv = bmv;
     return bcost;
-- 
2.43.0.windows.1







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20250319/d7610850/attachment-0001.htm>