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" <ccc7...@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" <ccc7...@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 <chenm...@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
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel
