x265 HEVC Encoder

[Ma]

For me the clip lighthouse_lossless.mp4 is interesting because of the sky -- it is challenging to encode this clip at low bitrates to be not annoying if you look at the sky. There are not sharp details -- it is about the gradients. PSNR is not perfect but for the sky it is OK.

For me at low bitrates aq-mode 1 is the least annoying, for medium bitrates aq-mode 3 is OK too. The default aq-mode 2 is not the best at low and medium bitrates with this clip (for me).

[Ma]

It looks like there is (at least one) bug in '--hevc-aq' option.
Workaround is quite simple, please use
--hevc-aq --no-cutree
instead of plain '--hevc-aq' option.

[imhh11]

Originally Posted by imhh11

Thanks for the update.

is DV profile 5 single layer ?
if yes, then does it mean we can now convert our 2 layer DV uhd disc to a single layer file playable via usb into our TV ?

Originally Posted by jlpsvk

i would like to know that too. and if yes, how.

even better, we can now mux DV layers (without re-encoding) into a mp4 file playable in my DV TV.

https://extraimage.net/images/2018/1...71dc566510.png

only work with AC3 / E-AC-3 / AC-4 / AAC audio though.

https://github.com/DolbyLaboratories/dlb_mp4base

mp4muxer --dv-profile 7 --input-file (baselayername.hevc1) --input-file (dvlayername.hevc2) --input-file (audio.ac3) --media-lang eng --output-file (nameofmovie).mp4

[SeeMoreDigital]

Originally Posted by imhh11

...only work with AC3 audio though.

Actually, the new .MP4 muxer supports the following audio formats: Dolby Digital (AC-3), Dolby Digital Plus (E-AC-3) and Dolby AC-4 audio formats. Along with all AAC flavours.

Cheers

[DJATOM]

Originally Posted by Ma

It looks like there is (at least one) bug in '--hevc-aq' option.
Workaround is quite simple, please use
--hevc-aq --no-cutree
instead of plain '--hevc-aq' option.

We (Beatrice-Raws) also discovered some annoying bug with --aq-motion. It's easy to trigger that on the static background and a single moving object. Samples reproducing that issue here.

[Aruna Matheswaran]

Hello Everyone,
Our latest blog on Dolby Vision integration into x265 is out! Do check out the blog @ http://x265.org/x265-delivers-dolby-vision-streams/

[agressiv]

Looks like 3.0 will be released soon?

[LigH]

Originally Posted by Wolfberry

x265-3.0_RC+2-5251075203e1-win64-static+shared [ICC 1900]

No real difference compared to previous build.

Doesn't build in MSYS2/MinGW — I believe because the Win Resource Compiler doesn't accept non-number parts of the version string, and "0_RC" is not a number.

[agressiv]

Originally Posted by Aruna Matheswaran

Hello Everyone,
Our latest blog on Dolby Vision integration into x265 is out! Do check out the blog @ http://x265.org/x265-delivers-dolby-vision-streams/

Anyone have a real-world example (with sample clips?) of this function?

I've extracted a secondary HEVC stream from a Dolby Vision UHD blu-ray with tsMuxer and tried to use that as the --dolby-vision-rpu parameter, but I'm guessing it's looking for something different. Encoder aborts about 5 seconds in.

x265 [error]: Invalid Dolby Vision RPU size in POC 8218:19:24

I'd love to get this working and not have to deal with multiple streams for DV.

[chinobino]

Originally Posted by Aruna Matheswaran

Hello Everyone,
Our latest blog on Dolby Vision integration into x265 is out! Do check out the blog @ http://x265.org/x265-delivers-dolby-vision-streams/

Exciting stuff!

Looks like v3 will have a lot of new features.

[FranceBB]

Originally Posted by Aruna Matheswaran

Hello Everyone,
Our latest blog on Dolby Vision integration into x265 is out! Do check out the blog @ http://x265.org/x265-delivers-dolby-vision-streams/

Very interesting, indeed.
Unfortunately I don't have any Dolby Vision file to extract the Dolby Vision RPU and fancy an encode, though.

[SeeMoreDigital]

Originally Posted by agressiv

Anyone have a real-world example (with sample clips?) of this function?

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...

[Ma]

Originally Posted by DJATOM

We (Beatrice-Raws) also discovered some annoying bug with --aq-motion. It's easy to trigger that on the static background and a single moving object. Samples reproducing that issue here.

Yes, I see the problem. There are 3 functions that make quality of the one butterfly on static background worse:
--aq-mode
--cutree
--aq-motion
All of them penalize CU with butterfly and the result is extremely low quality in one place. It should be some limit in x265 that if all 3 functions penalize one place, the applied quality penalty is not bigger than some MAX_PENALTY.

As a workaround we could use only 2 of these 3 functions and/or lower aq-strength.

[asarian]

Originally Posted by Aruna Matheswaran

Hello Everyone,
Our latest blog on Dolby Vision integration into x265 is out! Do check out the blog @ http://x265.org/x265-delivers-dolby-vision-streams/

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

[benwaggoner]

Originally Posted by Ma

I decided to test aq-mode 0/1/2/3 vs. hevc-aq at preset veryslow encoding lighthouse_lossless.mp4 to 10-bit hevc at bitrates 750/1500/3000/6000.

…

hevc-aq is not ready yet -- especially first pass is totally broken.
It's funny like aq-mode 1 wins at small bitrates and looses at high (even with aq-mode 0).

Did you do a visual comparison? It's pretty typical that psychovisual improvements in AQ will reduce PSNR, and even SSIM in some cases.

[benwaggoner]

Originally Posted by Ma

Yes, I see the problem. There are 3 functions that make quality of the one butterfly on static background worse:
--aq-mode
--cutree
--aq-motion
All of them penalize CU with butterfly and the result is extremely low quality in one place. It should be some limit in x265 that if all 3 functions penalize one place, the applied quality penalty is not bigger than some MAX_PENALTY.

As a workaround we could use only 2 of these 3 functions and/or lower aq-strength.

Sounds like there is some sort of race condition happening. Better to fix that than just have a parameter to limit the impact of the features, which could reduce quality in other kinds of content.

That said, aq-motion is still experimental. I wouldn't trust it as a "Default On" feature without a lot of testing.

[benwaggoner]

Originally Posted by Boulder

Hevc-aq replaces the other aq-modes so now we have 4 possible aq-modes to use. Somehow it looks to me that qp-adaptation-range is available to all modes. It really should be tested to see what it actually does. The problem with these new parameters and functionalities has lately been the fact that no one explains why they were implemented (which scenarios will probably benefit and which may suffer). Also the test cases would be interesting to see and compare.

Really? it seems it should be --aq-mode 4, then, if it is exclusive to the others.

[benwaggoner]

Originally Posted by benwaggoner

Really? it seems it should be --aq-mode 4, then, if it is exclusive to the others.

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.

[benwaggoner]

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.

It wouldn't be any HDR->SDR conversion. The base layer would just be the SDR. I don't know of any real-world use of Profile 8.2, but I imagine it would be mainly used to take SDR sources and add metadata for how it should be enhanced for HDR. It is probably possible to derive profile 8.2 from an HDR DoVi master. But I don't know if full HDR dynamic range could be reconstructed without an actual secondary media layer, or a metadata layer with LOTS of spatial tagging.

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

H.264 Dolby Vision was certainly used a bunch in early days. But I don't know why anyone would use it today; all consumer products I can think of that can display Dolby Vision have HEVC decoders.

But encoding isn't the hard part. The hard part is the shaping, inverse tone mapping, and metadata generation. Profile 8.1 is only easy because uncompressed HDR-10 is pretty much the raw format of a DoVi master (plus metadata). x26? doesn't even attempt to implement the complex tech required to do a good job converting between color volumes.

[asarian]

Originally Posted by benwaggoner

It wouldn't be any HDR->SDR conversion. The base layer would just be the SDR. I don't know of any real-world use of Profile 8.2, but I imagine it would be mainly used to take SDR sources and add metadata for how it should be enhanced for HDR. It is probably possible to derive profile 8.2 from an HDR DoVi master. But I don't know if full HDR dynamic range could be reconstructed without an actual secondary media layer, or a metadata layer with LOTS of spatial tagging.


H.264 Dolby Vision was certainly used a bunch in early days. But I don't know why anyone would use it today; all consumer products I can think of that can display Dolby Vision have HEVC decoders.

But encoding isn't the hard part. The hard part is the shaping, inverse tone mapping, and metadata generation. Profile 8.1 is only easy because uncompressed HDR-10 is pretty much the raw format of a DoVi master (plus metadata). x26? doesn't even attempt to implement the complex tech required to do a good job converting between color volumes.

Thanks for the great explanations!