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 7th January 2019, 17:45   #6601  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by benwaggoner View Post
Well, just did a test encode and it appears to be true



x265 [warning]: hevc-aq enabled, disabling other aq-modes



This is confusing syntax. We really should have aq-mode 4 and 5. aq-mode 4 would be HEVC-AQ, and 5 would be HEVC-AQ with low luma bias (like aq-mode 3 versus 2). The need for low-luma bias is content dependent, and we shouldn't be locked into one or another.



Also I am getting VBV violations multiple times a second. From the first two seconds of my test clip:



x265 [warning]: poc:0, VBV underflow (-2596808 bits)

x265 [warning]: poc:8, VBV underflow (-13025705 bits):06:32

x265 [warning]: poc:4, VBV underflow (-13047849 bits):38:49

x265 [warning]: poc:16, VBV underflow (-12824903 bits)11:58

x265 [warning]: poc:12, VBV underflow (-12960465 bits):23:11

x265 [warning]: poc:24, VBV underflow (-12939991 bits)27:49

x265 [warning]: poc:20, VBV underflow (-13441281 bits):34:43

x265 [warning]: poc:32, VBV underflow (-12651471 bits)23:47

x265 [warning]: poc:28, VBV underflow (-12985385 bits):28:15

x265 [warning]: poc:40, VBV underflow (-12559455 bits)20:36

x265 [warning]: poc:36, VBV underflow (-13122593 bits)24:13





Was the Experimental Feature tag left off for HEVC-AQ? I love the idea of improved AQ, but it would be good to have a clear indication in the help text about how close to production ready this feature is.
In talking with MCW, they confirmed that

A) The new HEVC-aq is in fact experimental, ala AQ-motion
B) It does override the specified AQ-mode, and there is no way to get low-luma bias ala AQ-mode 3 yet.
C) Rate control should be working. I used a high-grain clip with some atypical properties in my initial test (because AQ was messing up on it before), so if anything was going to give it pause, it was that one.


Sent from my iPad using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th January 2019, 20:28   #6602  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
i'm trying to encode a 4k hevc file using an DV Enhancement Layer, i have a few question in this regard:
Can i crop the input frame?
Can i see from a MediaInfo log that the DV Layer got muxed inside the stream?
Can i mux the resulting h265 file into a mkv container?
Do i need to set DV Profile 8.1 to mux the additional layer?

Regards.
MonoS is offline   Reply With Quote
Old 8th January 2019, 22:30   #6603  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by MonoS View Post
i'm trying to encode a 4k hevc file using an DV Enhancement Layer, i have a few question in this regard:
Can i crop the input frame?
Can i see from a MediaInfo log that the DV Layer got muxed inside the stream?
Can i mux the resulting h265 file into a mkv container?
Do i need to set DV Profile 8.1 to mux the additional layer?.
I am not sure what you are trying to do, but I am doubtful it would work . Can you clearly define what your sources and desired outputs are? If you don’t already have an RPU file previously generated, you can’t do Profile 8.1. and there aren’t low-cost tools to generate one. ColorFront Transkoder is the most accesssble option I’m aware of.

Also, Profile 8.1 support isn’t common yet; the majority of existing Dolby Vision TVs in consumer hands today don’t support it. Profile 5 is what is universally supported.

The actual compression part is a relatively small and relatively straightforward part of making Dolby Vision content. Getting a properly shaped non-backwards compatible Y’CtCp source file and it’s metadata is the new and complex part.

Dolby Vision is a ways away from being something a consumer can make. It is totally feasible technically, but the tools just aren’t broadly available at this point.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th January 2019, 19:08   #6604  |  Link
Forteen88
Herr
 
Join Date: Apr 2009
Location: North Europe
Posts: 556
Quote:
Originally Posted by Jamaika View Post
I created a version for Windows 2.9+8. I almost doesn't change anything. Codec hasn't only 'threads' for VMAF as I wrote earlier.
https://www.sendspace.com/file/r90y0d
Probably it can also be created in MSVC.
Could you please make a x265-VMAF version for the latest x265 (v3.0 RC4)?
Forteen88 is offline   Reply With Quote
Old 9th January 2019, 20:30   #6605  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by Barough View Post
x265 v3.0_RC+4-8aebc58efe5c (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default

Is quite a bit slower than current version i'm using (2.9.9)

Test Settings:
1080p source
--crf 18 --preset veryslow --profile main10 --level-idc 4 --output-depth 10 --ctu 32 --psy-rdoq 2.5 --tskip --aq-mode 3 --qcomp 0.7 --vbv-bufsize 20000 --vbv-maxrate 20000 --ipratio 1.35 --pbratio 1.25 --subme 7 --merange 64 --colormatrix bt709 --deblock -1:-1 --no-sao

x265 2.9.9 (64bit GCC 8.2.0) avg. speed: 0.66fps
x265 3.0 RC4 (64bit GCC 8.2.1) avg. speed: 0.40fps

Last edited by K.i.N.G; 9th January 2019 at 20:50.
K.i.N.G is offline   Reply With Quote
Old 9th January 2019, 21:21   #6606  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Quote:
Originally Posted by benwaggoner View Post
I am not sure what you are trying to do, but I am doubtful it would work . Can you clearly define what your sources and desired outputs are?
sure i can, my apologies for not being clear from the start
I have a standard 4k bluray and i've extracted the tracks using the latest eac3to, so i have a source.mkv and dv_layer.h265 and i want to encode video and mux the additional Dolby Vision layer using the --dolby-vision-rpu option, but i don't know if the process is successful because i can't see any additional information when i generate a MediaInfo report.

I would like to crop the video stream as I'm encoding it then mux the resulting video into a mkv file.

TL;DR: how do i check that the muxing of the layer went fine? can i crop the picture? can i mux the resulting video stream to MKV?
MonoS is offline   Reply With Quote
Old 9th January 2019, 21:29   #6607  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Quote:
Originally Posted by K.i.N.G View Post
x265 2.9.9 (64bit GCC 8.2.0) avg. speed: 0.66fps
x265 3.0 RC4 (64bit GCC 8.2.1) avg. speed: 0.40fps
New --preset slower == old --preset veryslow and new --preset veryslow is really new and really veryslow. See https://bitbucket.org/multicoreware/...a23?at=default

To exact compare please use in new version command line '--preset slower' instead of old '--preset veryslow'
Ma is offline   Reply With Quote
Old 10th January 2019, 02:22   #6608  |  Link
agressiv
Registered Loser
 
agressiv's Avatar
 
Join Date: Dec 2004
Posts: 117
Quote:
Originally Posted by MonoS View Post
sure i can, my apologies for not being clear from the start
I have a standard 4k bluray and i've extracted the tracks using the latest eac3to, so i have a source.mkv and dv_layer.h265 and i want to encode video and mux the additional Dolby Vision layer using the --dolby-vision-rpu option, but i don't know if the process is successful because i can't see any additional information when i generate a MediaInfo report.

I would like to crop the video stream as I'm encoding it then mux the resulting video into a mkv file.

TL;DR: how do i check that the muxing of the layer went fine? can i crop the picture? can i mux the resulting video stream to MKV?
MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.
agressiv is offline   Reply With Quote
Old 10th January 2019, 05:33   #6609  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by agressiv View Post
MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.
Yeah, .mkv isn’t a professional format. Pretty much all professional development around containers these days is around mp4, and to a lesser and declining degree, MPEG transport streams.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th January 2019, 13:41   #6610  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.0_RC+10-672ce0547e97 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (32bit : GCC 7.4.0 / 64bit : GCC 8.2.1)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default

Last edited by Barough; 10th January 2019 at 16:27.
Barough is offline   Reply With Quote
Old 10th January 2019, 20:13   #6611  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Quote:
Originally Posted by agressiv View Post
MKV doesn't support Dolby Vision (at least, not yet) - it won't work. Your best bet is to use the Dolby MP4 muxer and use ac3 audio.
So what's the purpose of the --dolby-vision-rpu option?
If i understood correctly it should mux the DV metadate directly inside the h265 stream (and studying the relevant commit it seems to include such information inside an 0x3E NAL unit) so why i shouldn't be able to mux the resulting stream inside an mkv?
MonoS is offline   Reply With Quote
Old 10th January 2019, 23:41   #6612  |  Link
agressiv
Registered Loser
 
agressiv's Avatar
 
Join Date: Dec 2004
Posts: 117
Quote:
Originally Posted by MonoS View Post
So what's the purpose of the --dolby-vision-rpu option?
If i understood correctly it should mux the DV metadate directly inside the h265 stream (and studying the relevant commit it seems to include such information inside an 0x3E NAL unit) so why i shouldn't be able to mux the resulting stream inside an mkv?
DV metadata for x265, but not necessarily the elementary h265 stream from a blu-ray.

We have yet to see a clip which works with --dolby-vision-rpu. And once we get it, we can only use .ts or .mp4, not .mkv.

If you have one, we're all ears, but nothing from a UHD blu-ray works with that parameter with x265.
agressiv is offline   Reply With Quote
Old 11th January 2019, 00:29   #6613  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 11th January 2019, 10:42   #6614  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
@Ma

I asked some questions regarding mereange a while ago but didnt get a reply, so I thought that I give it another shot.

I've seen discussions here and in other threads that CTU 64 is overkill for resolutions bellow 4k, and I've seen from my own testing that lowering CTU from 64 to 32 on systems with plenty of threads gives an speed improvment of up to 50% for 1080p video, and lowering merange gives another 10%. And this is with a very minor compression hit. This behavior is also stated in this document https://media.readthedocs.org/pdf/x265/default/x265.pdf when it comes to threading performance.

What I find a bit odd is that this is stated in the document: "Given these considerations, you can understand why the faster presets lower the max CTU size to 32x32 (making
twice as many CTU rows available for WPP and for finer grained frame parallelism) and reduce --merange"
and this: "The default is derived from the default CTU size (64) minus the luma interpolation half-length (4) minus maximum subpel distance (2) minus one extra pixel just in case the hex search method is used."

But I cant see that any preset changes the merange value of 57, even the two fastes ones that do lower the CTU value to 32. How come? And since lowering CTU (and merange), can have such massive influence on speed, wouldn't be a good idea to have these values set based on resolution?

And giving the explanation of the default merange value, would the same calculation stand when lowering CTU to say 32? I.e. would that give an "best practice" value of 26 if me star is used?

Last edited by excellentswordfight; 11th January 2019 at 10:50.
excellentswordfight is offline   Reply With Quote
Old 11th January 2019, 20:11   #6615  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
Quote:
Originally Posted by agressiv View Post
We have yet to see a clip which works with --dolby-vision-rpu. And once we get it, we can only use .ts or .mp4, not .mkv.
I thought that the Dolby Video Enhancement Layer available in commercially available BDs where the RPU information, if i'm understanding correctly this is not the case, but x265 wasn't giving me any error (like you can see here https://bitbucket.org/multicoreware/...e/x265.cppT587 ) so i expected to be doing things right.

Quote:
Originally Posted by LigH View Post
DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...
It won't happen again
MonoS is offline   Reply With Quote
Old 11th January 2019, 20:27   #6616  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by MonoS View Post
I thought that the Dolby Video Enhancement Layer available in commercially available BDs where the RPU information, if i'm understanding correctly this is not the case, but x265 wasn't giving me any error (like you can see here https://bitbucket.org/multicoreware/...e/x265.cppT587 ) so i expected to be doing things right.
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.

It won't happen again [/QUOTE]
I like DoVi as the short way to type it. I am an old fellow, and I hear DV I start thinking "Ah, 25 Mbps with 720x480 4:1:1 color in its NTSC variant." It's amazing what we can do with 25 Mbps a couple decades later!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 11th January 2019, 20:43   #6617  |  Link
MonoS
Registered User
 
Join Date: Aug 2012
Posts: 203
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, 23:20   #6618  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
--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, 51 views)
Ma is offline   Reply With Quote
Old 12th January 2019, 04:41   #6619  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 709
@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, 12:17   #6620  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
why the hell was default aq-mode changed to 2 from 1???? my all encodes are bad now.
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD
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 22:33.


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