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 11th January 2019, 19:43   #6621  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 176
Quote:
Originally Posted by benwaggoner View Post
I think the older discs were mainly Profile 5, where the enhancement layer includes both quarter-scale video and metadata. x265 doesn't support that. Newer discs would be Profile 5, where the enhancement layer is just RPU metadata. But that requires a properly "shaped" base layer specific to the source and metadata, which is Y'CtCp and dynamically adjusts to the currently-used subset of the PQ curve for greater precision.
I think that what i'm talking about it's BDs with DoVi 7.6 (as per this document https://www.dolby.com/us/en/technolo...les-levels.pdf ) so standard 4k video content and additional enhancement layer
MonoS is offline   Reply With Quote
Old 11th January 2019, 22:20   #6622  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
--ctu 64 vs. 32 && --merange 12 vs. 26 vs. 40 vs. 57 vs. 74 vs. 92

I've made a test with --merange 12/26/40/57/74/92 for --ctu 64 --qg-size 64 vs. --ctu 32 --qg-size 32

Command line:
for %m in (12 26 40 57 74 92) do (
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --qg-size 64 --merange %m ../big_buck_bunny_1080p24.y4m w64-%m.hevc
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --ctu 32 --merange %m ../big_buck_bunny_1080p24.y4m w32-%m.hevc
)

Results (in ctu block: speed (fps), PSNR, SSIM (dB)):
Code:
					ctu		
merange	|		64		|		32	
12	|	6.93	39.980	12.996	|	6.44	39.565	12.742
26	|	6.69	40.303	13.599	|	6.21	39.903	13.345
40	|	6.46	40.393	13.746	|	6.07	39.999	13.499
57	|	6.13	40.404	13.757	|	5.90	40.019	13.512
74	|	5.85	40.409	13.757	|	5.67	40.024	13.515
92	|	5.58	40.413	13.760	|	5.47	40.026	13.514
When --merange grows, the quality increases regardless of the size of --ctu (it may depend on the source movie).

For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding.
Attached Files
File Type: txt screen.txt (27.4 KB, 13 views)
Ma is offline   Reply With Quote
Old 12th January 2019, 03:41   #6623  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 701
@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 12th January 2019, 11:17   #6624  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
why the hell was default aq-mode changed to 2 from 1???? my all encodes are bad now.
__________________
Core i9-7960X, 64GB DDR4, RTX 2070, 1TB NVMe SSD, 56TB NAS
jlpsvk is offline   Reply With Quote
Old 12th January 2019, 11:24   #6625  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,754
If you rely on a specific setting that strongly, you should not rely on it being the default, and just specify it. Or as an alternative, not blindly update your encode pipeline without verifying that it still produces expected results.
For the record, the default was changed from 1 to 2, not the other way around.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 12th January 2019, 11:35   #6626  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
Quote:
Originally Posted by nevcairiel View Post
If you rely on a specific setting that strongly, you should not rely on it being the default, and just specify it. Or as an alternative, not blindly update your encode pipeline without verifying that it still produces expected results.
For the record, the default was changed from 1 to 2, not the other way around.
That's the reason why I have a long string of options in the command line even if most of them are the defaults of a specific preset.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 12th January 2019, 11:48   #6627  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,754
Personally I like the second option. Not blindly update, but validate new versions first.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 12th January 2019, 11:56   #6628  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,836
Still waiting for them to update the documentation https://x265.readthedocs.io/en/latest/presets.html,..
Opened an issue entry for it (https://bitbucket.org/multicoreware/...-documentation) at the end of last year.
I get it that they change the defaults(/presets/tune) from time to time, but not updating the documentation do represent such fundamental changes is really annoying,...
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 12th January 2019, 12:10   #6629  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
And a funny thing is that --no-rskip is supposed to be a default in --preset veryslow (and also --slower) but it's not according to the code. I reported the issue a long time ago but no one fixed it Doesn't matter to me though, I use --rskip all the time anyway.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 12th January 2019, 12:26   #6630  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,836
@Boulder: yeah, looking at https://bitbucket.org/multicoreware/...cpp?at=default rskip is only disabled in placebo,
but the documentation:
- https://x265.readthedocs.io/en/latest/presets.html reports that is is disabled starting with slower.
- https://x265.readthedocs.io/en/default/presets.html reports that is is disabled starting with very slow.
-> wrong documentation is even worse than missing documentation
(same for https://bitbucket.org/multicoreware/....cpp?at=latest)
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 12th January 2019, 13:29   #6631  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18
__________________
Core i9-7960X, 64GB DDR4, RTX 2070, 1TB NVMe SSD, 56TB NAS
jlpsvk is offline   Reply With Quote
Old 12th January 2019, 13:44   #6632  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
Quote:
Originally Posted by jlpsvk View Post
ok... can you tell me why aq mode 2 is better? i noticed rapid lower bitrate with aq-mode 2... any impact on picture quality and fine detail retention? i am encoding with crf18
I didn't find mode 2 better than 1 in my test cases (reported earlier here in this thread) so I'm still using mode 1 with the default strength.

I think you need to find a new sweet spot for CRF since the bitrate demand is indeed quite different compared to mode 1, and I also think it depends heavily on the content.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 12th January 2019, 14:35   #6633  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Quote:
Originally Posted by Motenai Yoda View Post
@Ma can you make results about --ctu 64 --qg-size 32 and --ctu 32 --qg-size 16 too?
maybe just for --merange 40 only
Results in attachment -- it is a bit faster encoding but quality is worse (at the same bitrate).
Attached Files
File Type: txt screen2.txt (27.5 KB, 42 views)
Ma is offline   Reply With Quote
Old 12th January 2019, 16:57   #6634  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 93
Quote:
Originally Posted by Ma View Post
I've made a test with --merange 12/26/40/57/74/92 for --ctu 64 --qg-size 64 vs. --ctu 32 --qg-size 32

Command line:
for %m in (12 26 40 57 74 92) do (
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --qg-size 64 --merange %m ../big_buck_bunny_1080p24.y4m w64-%m.hevc
x265 -p7 --bitrate 500 -f3333 --psnr --ssim --ctu 32 --merange %m ../big_buck_bunny_1080p24.y4m w32-%m.hevc
)

Results (in ctu block: speed (fps), PSNR, SSIM (dB)):
Code:
					ctu		
merange	|		64		|		32	
12	|	6.93	39.980	12.996	|	6.44	39.565	12.742
26	|	6.69	40.303	13.599	|	6.21	39.903	13.345
40	|	6.46	40.393	13.746	|	6.07	39.999	13.499
57	|	6.13	40.404	13.757	|	5.90	40.019	13.512
74	|	5.85	40.409	13.757	|	5.67	40.024	13.515
92	|	5.58	40.413	13.760	|	5.47	40.026	13.514
When --merange grows, the quality increases regardless of the size of --ctu (it may depend on the source movie).

For CPU with only 12 logical cores (6 physical) --ctu 64 is just better in preset slower for 1080p encoding.
I see, thanks for sharing.

I think you are correct, since the biggest benefit of reducing it only appears when going above arround 8C/16T (I was testing with 12/24 and went from 7fps to 11fps cause of the less thread utilization at CTU 64, and I would say that it was definitely was worth the trade off), it does makes since to keep it as an manual setting.

I would say though that it might be worth consideration to lower the merange for those fastets presets, since it doesnt seem to benefit quality that much.

Last edited by excellentswordfight; 12th January 2019 at 16:59.
excellentswordfight is offline   Reply With Quote
Old 13th January 2019, 13:40   #6635  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,875
Quote:
Originally Posted by benwaggoner View Post
I like DoVi as the short way to type it.
That might sound stupid to a German (Doofi ~ retarded kid)

Quote:
Originally Posted by benwaggoner View Post
a couple decades later!
I am old!
_

Some on-topic:

Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.

To me, it seems that supporting such data is mainly for professional content producers. Might be a field where hobbyists can't help the developers much.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 13th January 2019, 13:55   #6636  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,404
Quote:
Originally Posted by LigH View Post
Support for Dolby Vision is announced, and immediately people believe that applications for decoding, possibly even encoding, for consumer PCs are available too ... which is doubtful. I wonder how "homeopathic" its additional features will be in a generic furnished living room, where average people can hardly tell the difference between DD AC3 and dts on a DVD Video, not to mention HD Audio formats.
Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior. Just like in the past authors used different mixes for AC3 and DTS tracks on the same DVD. It's all about marketing.
sneaker_ger is offline   Reply With Quote
Old 13th January 2019, 16:39   #6637  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
Quote:
Originally Posted by sneaker_ger View Post
Oh, I'm sure the difference will be noticable to consumers. Simply because authors will make it so, not because it's superior.
That.
jd17 is offline   Reply With Quote
Old 14th January 2019, 23:31   #6638  |  Link
Lucius Snow
Registered User
 
Join Date: Oct 2003
Location: Paris, France
Posts: 83
Hello all,

There's still no GPU support to speed up the encoding?

Thanks.
Lucius Snow is offline   Reply With Quote
Old 15th January 2019, 02:00   #6639  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,875
No. I believe because GPU features would not speed x265 up. At least not without risking a loss of quality or losing the independence from hardware and software platforms (portability).

GPU features are not magical general speed-ups for every case of use, sometimes they just don't match the requirements.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 15th January 2019, 08:55   #6640  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
Ok. Did a test. 3840x2160 res., same x265 settings. One with aq-mode 1 crf18 and second aq-mode 2 (which is now new default) with crf16. aq-mode 2 with crf16 still gives lower bitrate. which one "should" be better in terms of detail retention?

whole CLI (HDR parameters are added automatically by RipBot264):
Code:
-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 1 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 18
Code:
-preset slow --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --aq-mode 2 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr --hdr-opt --repeat-headers --no-info --no-deblock --no-sao --allow-non-conformance --no-strong-intra-smoothing --high-tier --asm avx512 --crf 16
__________________
Core i9-7960X, 64GB DDR4, RTX 2070, 1TB NVMe SSD, 56TB NAS

Last edited by jlpsvk; 16th January 2019 at 11:05.
jlpsvk 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 14:15.


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