x265 HEVC Encoder

[jlpsvk]

Originally Posted by asarian

Wonderful!

If I understood the process right, I'm most interested in 'Profile 8.2 single layer with SDR compatibility' myself, as any extra layer that can be used for a better HDR->SDR conversion, will be very welcome.

I guess this also means you guys have 'cracked' the DV layer, and it's now known how to handle the meta-data therein, right?

Bit off-topic, perhaps, but I wouldn't mind seeing DV SDR layer info getting added to x264 too, one day (after all, x264 has always been predominantly about 8-bit).

why the hell you would downgrade HDR10 base to SDR? Main interest should be Profile 8.1. But still.... what is the DV RPU METADATA file? Is that the second HEVC stream on UHD BD disc?

[algorithm_colon]

Originally Posted by SeeMoreDigital

Is this 'video only' sample (supplied by algorithm_colon) what you're looking for: https://forum.doom9.org/showthread.p...29#post1861429

I've been able to add audio Dolby Digital and AAC audio to it using a standard MP4Box build...

I tried using the same input files (base layer and metadata layer) to x265 as I used with the dolby tool and I get the same "Invalid Dolby Vision RPU" error

[Barough]

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)

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

[benwaggoner]

Originally Posted by jlpsvk

why the hell you would downgrade HDR10 base to SDR? Main interest should be Profile 8.1. But still.... what is the DV RPU METADATA file? Is that the second HEVC stream on UHD BD disc?

The RPU is just the metadata. Profiles 5 and 8.* don’t use a second encoded video layer. That’s just a legacy mode these days, as the dual-layer approach had a lot more bitrate and decode overhead.

Dual layer made a lot of sense when 8-bit H.264 encoders were standard, but with 10-bit HEVC it because a lot less necessary. Plus all the non-backwards compatible shaping used in Profile 5.


Sent from my iPad using Tapatalk

[benwaggoner]

Originally Posted by benwaggoner

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

[MonoS]

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.

[benwaggoner]

Originally Posted by MonoS

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.

[Forteen88]

Originally Posted by Jamaika

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)?

[K.i.N.G]

Originally Posted by Barough

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)

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

[MonoS]

Originally Posted by benwaggoner

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?

[Ma]

Originally Posted by K.i.N.G

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'

[agressiv]

Originally Posted by MonoS

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.

[benwaggoner]

Originally Posted by agressiv

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.

[Barough]

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)

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

[MonoS]

Originally Posted by agressiv

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?

[agressiv]

Originally Posted by MonoS

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.

[LigH]

DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...

[excellentswordfight]

@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?

[MonoS]

Originally Posted by agressiv

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.

Originally Posted by LigH

DV is still "Digital Video" for me, not "Dolby Vision", so I keep wondering about metadata...

It won't happen again

[benwaggoner]

Originally Posted by MonoS

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!