Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd February 2018, 12:26   #5881  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
Quote:
Originally Posted by WhatZit View Post
http://ieeexplore.ieee.org/stamp/sta...number=6324414

The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION.

STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units.

The default value of 0 activates on relatively balanced values between the block boundaries.

The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing.

The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts.

To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately.

To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit.

I personally use -2,-3.
I am using CRF16 with x265 4K HDR encodes. So the bitrate is not limiting, i think.
jlpsvk is offline   Reply With Quote
Old 2nd February 2018, 15:27   #5882  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
x265.exe 2.6+37-1949157705ce

https://forum.videohelp.com/threads/...42#post2510642
Midzuki is offline   Reply With Quote
Old 3rd February 2018, 18:10   #5883  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 481
x265 v2.6+37-1949157705ce (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 3rd February 2018, 19:20   #5884  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
@Barough - interesting, your version info strings still work:

Code:
x265 [info]: HEVC encoder version 2.6+37-1949157705ce
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
Mine only display "(null)". Possibly because my MSYS2 environment updated to a buggy binutils version or similar... I hope the MABS developers will find a workaround until the package providers offer updates.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd February 2018, 19:46   #5885  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 481
@LigH - I ran the update on MABS today and it updated just fine. Have done 2 test encodes with the new x265 through MeGUI and it worked perfect
Barough is offline   Reply With Quote
Old 3rd February 2018, 21:12   #5886  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
@LigH - the bug in binutils 2.30 for mingw target is huge, the compiler cannot create executables. If you build the x265.exe encoder it means you probably use binutils 2.29.1.

Mercurial was moved from mercurial.selenic.com to mercurial-scm.org and this is prime suspect for the problem. You can try to execute
Code:
hg clone https://bitbucket.org/multicoreware/x265
from msys2 shell to some new location and use new x265 folder only with new version of HG (from msys2).
Ma is offline   Reply With Quote
Old 3rd February 2018, 22:15   #5887  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
I can build it ... despite:
Code:
[2018-01-29 21:24] [ALPM] upgraded mingw-w64-x86_64-binutils (2.29.1-1 -> 2.30-1)
If I knew how to tell the MSYS2 environment of MABS to downgrade, I could do that. And I am pretty sure that wiiaboo knows about this issue.

And because updating x265 failed with an "unresolved merge", I recently let the whole x265 source get cloned anew, by deleting the whole build/x265-hg directory.

There is a new proposed patch to generate the hg version information in a different way, this is not yet committed.

It's so confusing ... so many reasons why the base system of two users can be different enough that doing the same which is supposed to bring both systems to the same state still produces different results.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 3rd February 2018 at 22:19.
LigH is offline   Reply With Quote
Old 4th February 2018, 13:07   #5888  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:

32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output

x265 2.6+37-1949157705ce (MSYS2/MinGW, GCC 7.3.0)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 4th February 2018, 23:35   #5889  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
I would suggest a possible tune animation:
Code:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1
under evalutation (some unclear detail loss)
Code:
ref +1 bframes +2
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 5th February 2018, 14:30   #5890  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Quote:
Originally Posted by Motenai Yoda View Post
I would suggest a possible tune animation:
I've prepared first version of anime patch with main part:
Code:
+        else if (!strcmp(tune, "anime"))
+        {
+            param->rc.aqMode = 3;
+            param->rc.aqStrength = 0.6;
+            param->bAQMotion = 1;
+            param->rc.qgSize = 16;
+            param->lookaheadDepth += 20;
+            param->psyRd = 1.2;
+            param->rdoqLevel = 2;
+            param->psyRdoq = 0.3;
+            param->bEnableLoopFilter = 1;
+            param->deblockingFilterTCOffset = 1;
+            param->deblockingFilterBetaOffset = -1;
+            param->cbQpOffset = -1;
+            param->crQpOffset = -1;
+        }
Windows binaries for testing + patch file anime.7z
Ma is offline   Reply With Quote
Old 5th February 2018, 20:46   #5891  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
I'd rather be glad to take into account somebody else's opinion about it too
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 5th February 2018, 20:56   #5892  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
With a readily provided test encoder, that's easier than in theory. Or with lengthy CLI param lists.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 7th February 2018, 00:39   #5893  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
From my tests the option '--qg-size 16' is broken -- in all bitrates decrease quality.
I don't like '--aq-motion', so my 'anime' proposition is:
--rc-lookahead *= 2;
--psy-rd /= 2;
--keyint *= 2;
if (rdoq-level > 0)
{
--cbqpoffs -1; --crqpoffs -1;
}
if (preset >= 7) // slower, veryslow & placebo
{
--frame-threads 1;
}
Ma is offline   Reply With Quote
Old 7th February 2018, 09:35   #5894  |  Link
Arhu
Registered User
 
Join Date: Nov 2003
Posts: 12
I always use aq-mode 3 (10 bit) but regularly had banding issues with aq-strength < 1. Could anyone else observe this?
Arhu is offline   Reply With Quote
Old 7th February 2018, 15:45   #5895  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
MSYS2 released binutils-2.30-2; static binaries should work again.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th February 2018, 21:06   #5896  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.

My test was encoding first 2222 frames of big_buck_bunny_1080p24.y4m with preset slower, tune anime (which I renamed to cartoon), 10-bit output, ABR mode with bitrates: 300, 450, 750, 1200 and 1950, qg-size from 8 to 64.
Command line:
Code:
for %b in (300 450 750 1200 1950) do (for %q in (8 16 32 64) do 
(x265 -D10 --psnr --ssim -p7 -f2222 --tune cartoon --bitrate %b --qg-size %q ../big_buck_bunny_1080p24.y4m m%b-%q.hevc))
The result Global PSNR/SSIM Mean Y dB is (bitrate\qg-size):
Code:
	8		16		32		64
300	37.554/11.452	37.538/11.520	37.643/11.568	37.781/11.638
450	39.056/12.742	39.026/12.781	39.143/12.843	39.281/12.907
750	40.993/14.407	40.962/14.445	41.099/14.522	41.225/14.559
1200	42.835/16.004	42.802/16.032	42.958/16.117	43.065/16.136
1950	44.746/17.661	44.713/17.692	44.866/17.774	44.950/17.781
Samples to watch:
bitrate 300: qg-size 16, qg-size 64
bitrate 450: qg-size 16, qg-size 64

So my question is: what should I look at to see the advantages of qg-size 16?
Ma is offline   Reply With Quote
Old 9th February 2018, 21:47   #5897  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,255
Quote:
It is a bit strange, the default value in x265 is 32.
Hmm,....
Quote:
--qg-size <64|32|16|8>

Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize]. Default: same as maxCUSize
source: http://x265.readthedocs.io/en/latest...#cmdoption-ctu
Quote:
--ctu, -s <64|32|16>

Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64
source: http://x265.readthedocs.io/en/latest...#cmdoption-ctu

-> Shouldn't the default be 64 and not 32?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 9th February 2018, 21:52   #5898  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
I remember that there was an issue with 64 (loss of details, or improper segmentation?)... but I do not remember if it was fixed yet.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th February 2018, 22:08   #5899  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
In documentation the default value of qg-size is 64, in real code it is 32. 'x265 --help' prints options and default values, if you encode there is line
Code:
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
It was probably changed from 64 to 32 and the documentation is not updated.
Anyway, the 32 value is a bit strange for me.
-----------
It was changed in 2015-08-03 by https://bitbucket.org/multicoreware/...c4da4450e9f84e

Last edited by Ma; 9th February 2018 at 22:33.
Ma is offline   Reply With Quote
Old 9th February 2018, 23:22   #5900  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,255
@Ma: thanks for the insight

Cu Selur
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 10th February 2018 at 00:08.
Selur is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.