x265 HEVC Encoder

[filler56789]

^ Thanks for answering.

Multilib builds are broken (and builds with ENABLE_HDR10_PLUS too).

OUCH! :-/ So I will have to wait.

Simplest solution:
diff -r 537bba0b7fdc source/encoder/encoder.cpp
--- a/source/encoder/encoder.cpp Thu Dec 27 11:56:52 2018 +0530
+++ b/source/encoder/encoder.cpp Thu Dec 27 14:25:51 2018 +0100
@@ -69,7 +69,7 @@
int doviProfileId;
}DolbyVisionProfileSpec;

-DolbyVisionProfileSpec dovi[] =
+static DolbyVisionProfileSpec dovi[] =
{
{ 1, 1, 1, 1, 1, 5, 1, 2, 2, 2, 50 },
{ 1, 1, 1, 1, 1, 5, 0, 16, 9, 9, 81 },
diff -r 537bba0b7fdc source/x265.cpp
--- a/source/x265.cpp Thu Dec 27 11:56:52 2018 +0530
+++ b/source/x265.cpp Thu Dec 27 14:25:51 2018 +0100
@@ -690,7 +690,7 @@
args[argCount++] = token;
token = strtok(NULL, " ");
}
- args[argCount] = '\0';
+ args[argCount] = NULL;
CLIOptions cliopt;
if (cliopt.parseZoneParam(argCount, args,param, i))
{

Since I didn't know the multilib builds are impossible for the time being,
the old error message

(something about "invalid conversion from char to char*")

just went replaced with a new one :-/

[Yanak]

Hi,
Introduce --tune animation option
--psy-rd 0.4
--aq-strength 0.4
--deblock 1:1
--bframes increased by 2

Sorry if it's a silly question but Bframes increased by 2, means +2 from the default parameter which is 4 Bframes according to the doc (https://x265.readthedocs.io/en/latest/cli.html#cmdoption-bframes), so it will be --bframes 6, or from 0 so it will be --bframes 2 ?

Thank you

[Wishbringer]

Or from bframes you give per commandline?
What has a higher priority?
I expect: +2 from preset, except explicit given by command, then the manual value

[LigH]

You will usually first use a preset, then a tuning (so the "animation" tuning will add 2 to the number of B frames of your preset); but if you also add an explicit bframes parameter later in the command line, it will supersede previously calculated values.

[RainyDog]

Looks like we have a new AQ mode in x265 2.9+28 :cool:

It scales the quantization step size according to the spatial activity of one coding unit relative to frame average spatial activity. This AQ method utilizes the minimum variance of sub-unit in each coding unit to represent the coding units spatial complexity.

Default 1.0.

**Range of values:** 0.0 to 3.0

+.. option:: --hevc-aq
+
+ Enable adaptive quantization
+ It scales the quantization step size according to the spatial activity of one
+ coding unit relative to frame average spatial activity. This AQ method utilizes
+ the minimum variance of sub-unit in each coding unit to represent the coding
+ unit’s spatial complexity.
+
+.. option:: --qp-adaptation-range
+
+ Delta-QP range by QP adaptation based on a psycho-visual model.
+
+ Default 1.0.
+ **Range of values:** 1.0 to 6.0

[Boulder]

Seems interesting. It would be nice to hear of the cases which this new method targets.

[Boulder]

x265 version 2.9+34-17120cf win64 [ICC 1900] (https://drive.google.com/open?id=1pqnbKmfE0pnvx-rlo5wYCB5OPMvuo_92)

libiomp5md.dll seems to be a dependency as I get a missing file warning. Where can I get that one (and others which may also be needed)?

[Forteen88]

libiomp5md.dll seems to be a dependency as I get a missing file warning. Where can I get that one (and others which may also be needed)?"libiomp5md.dll is from the Intel C compiler".
More info here, https://stackoverflow.com/questions/7270639/why-does-intel-compiler-produce-output-that-requires-libiomp5mt-dll-even-though

[Ma]

I found this statement about Intel C++:
***
If you want to link against the static OpenMP RTL, you must add /Qopenmp-link:static, which is a new switch for 11.0. So to produce a purely static executable, compile/link with /MT /Qopenmp-link:static
***

[Wolfberry]

@Ma
Thanks for the information.
Without /Qopenmp, /MT should be fine.
With /Qopenmp, /Qopenmp-link:static needs to be used to produce a purely static executable.

[Ma]

I hope that you pass /MT by
-DSTATIC_LINK_CRT=ON
CMake option.

[shinchiro]

In case, people want to play around with new hevc-aq: :)

x265-2.9+34-17120cfb5c99-multilibs-gcc-8.2.1.7z (https://transfer.sh/o933m/x265-2.9+34-17120cfb5c99-multilibs-gcc-8.2.1.7z)

[Yanak]

You will usually first use a preset, then a tuning (so the "animation" tuning will add 2 to the number of B frames of your preset); but if you also add an explicit bframes parameter later in the command line, it will supersede previously calculated values.

Or from bframes you give per commandline?
What has a higher priority?
I expect: +2 from preset, except explicit given by command, then the manual value

It makes sense, was a bit confused about it.

Thank you guys.

[mini-moose]

In the recent default branch builds, aq-mode default is now 2 instead of 1. Reading some on it, it seems (at least on paper) like a better mode to use: "applies separate aq-strength for each frame, based on the complexity of current frame. I tested on a short clip (10k frames) and it seems the avg bitrate with mode 2 is lower and avg qp is higher.
I'm not an expert so would appreciate comments on this.

The is also some feature called hevc-aq which I'm not sure what it does: Mode for HEVC Adaptive Quantization. Default disabled

Also see something called "no-splice" in mediainfo encoder settings, which I can't find any reference to in --full help.

[Boulder]

I did a quick 2-pass test and a CRF test encode and hevc-aq smoothed the flat background quite heavily in both cases. The bitrate rose quite a lot in CRF mode:

AQ-mode 1 : 4425 kbps
AQ-mode 2 : 4706 kbps
AQ-mode 3 : 5999 kbps
HEVC-AQ : 5094 kbps

I'm really not convinced that aq-mode 2 is a better option than mode 1. To me it seems to also smooth the flat areas too much and that becomes quite annoying once you start noticing the gradients that result from it. See the wall between the women.

Original frame before encoding:
https://i.postimg.cc/9w9HttFx/original.png (https://postimg.cc/9w9HttFx)

AQ-mode 1:
https://i.postimg.cc/wySSvycD/aqmode1.png (https://postimg.cc/wySSvycD)

AQ-mode 2:
https://i.postimg.cc/7J8WDvwV/aqmode2.png (https://postimg.cc/7J8WDvwV)

HEVC-AQ:
https://i.postimg.cc/xNvF1sdS/hevcaq.png (https://postimg.cc/xNvF1sdS)

[LigH]

Single frame screenshots often don't tell the impression of a movie clip accurately.

[Boulder]

Fortunately the testclips are quite small so I could put them in my Google Drive:

https://drive.google.com/open?id=1NrgUKJG0SJ8Y8Kat1j1fjYfflCArMx6C (aq-mode 1)
https://drive.google.com/open?id=1__fF2lLWGhqH1yB4DpfvuE55NBeMo_ui (aq-mode 2)
https://drive.google.com/open?id=1iWzq4i__QZYxdXXyNaNt7364LDlQQI2p (hevc-aq)

These are all 2-pass encodes with the same avg bitrate. To me hevc-aq smooths things too much, part of the problem is that the bitrate is not enough to keep up. Aq-mode 2 doesn't look as good as mode 1. Near the end of the clip, the difference between 1 and 2 is clearer as mode 2 has produced more swimming blocks in the flat background near the top of the image.

[tuanden0]

Fortunately the testclips are quite small so I could put them in my Google Drive:

https://drive.google.com/open?id=1NrgUKJG0SJ8Y8Kat1j1fjYfflCArMx6C (aq-mode 1)
https://drive.google.com/open?id=1__fF2lLWGhqH1yB4DpfvuE55NBeMo_ui (aq-mode 2)
https://drive.google.com/open?id=1iWzq4i__QZYxdXXyNaNt7364LDlQQI2p (hevc-aq)

These are all 2-pass encodes with the same avg bitrate. To me hevc-aq smooths things too much, part of the problem is that the bitrate is not enough to keep up. Aq-mode 2 doesn't look as good as mode 1. Near the end of the clip, the difference between 1 and 2 is clearer as mode 2 has produced more swimming blocks in the flat background near the top of the image.

Agree with you, --hevc-aq just smooth (blur) too much, some details were blurred and destroyed.

I tested with setting --preset slow --tune animation --crf 18 --hevc-aq

https://i.imgur.com/B0xclJl.png

[Selur]

Does '--hevc-aq' exclude the usage of '--aq-mode', I mean is it one or the other, or can they both be applied at the same time? (can't test myself atm.)
Also is '--qp-adaptation-range' a sub-option of '--hevc-aq' or '--aq-mode, or of both?

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

[Wolfberry]

qp-adaptation-range doesn't seem to do anything at the moment (There's no variance in final results nor I can find what it does in the code.)

[Selur]

Thanks for the help!

Hevc-aq replaces the other aq-modes so now we have 4 possible aq-modes to use.
may be we get lucky and they adjust the code so that there simply is a new mode for 'aq-mode' instead of a new flag,..

qp-adaptation-range doesn't seem to do anything at the moment (There's no variance in final results nor I can find what it does in the code.)
okay, so ignoring that parameter for now ;)

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).
100% agree

[Yanak]

Edit : nevermind, i think i finally figured it, looks like i needed a little break from the screen to ease a bit my mind and see a bit more clear in all this, having the nose pointed at all this stuff since hours now :p

Hi all,

I'm trying to compile x265 using VS2017 (just want to compare speed vs some releases, especially interested in the Intel compiler linked in my vs2017 as my old CPU supports max AVX only, a little gain will be nice, no matter if it's a tiny one),

I followed all the steps, installed all stuff needed and i can compile successfully the 8 or 10 or 12 Bits exe's but I'm scratching my head since a couple of hours about how to compile a multilib 8+10+12Bits version.

I launched the multilib.bat, it creates the 8,10,12bits folders and it starts to populate some of them with a bunch of stuff and then i get prompted by an error message "10bit build failed". I'm pretty sure I'm missing something obvious but don't know what.

- Do i need first to generate the Solution using make-solutions.bat and repeat the process 3 times, using cmake GUI and selecting the different depth options to in the end get one for each 8,10,12Bits depths and generate each .exe and only after that i can run the multilib.bat ?

After spending a few hours on this i'm a bit out of ideas, if anyone have any tips about the steps to follow to create the multilib 8+10+12Bits exe please ?

Thank you very much.

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

Command line:
for %b in (750 1500 3000 6000) do (
for %a in (0 1 2 3) do (
ffmpeg -i ../lighthouse_lossless.mp4 -v warning -f yuv4mpegpipe - | x265 --bitrate %b --y4m - --qg-size 64 --preset veryslow --psnr --ssim --aq-mode %a a%a-%b-1.hevc --pass 1
ffmpeg -i ../lighthouse_lossless.mp4 -v warning -f yuv4mpegpipe - | x265 --bitrate %b --y4m - --qg-size 64 --preset veryslow --psnr --ssim --aq-mode %a a%a-%b-2.hevc --pass 2
)
ffmpeg -i ../lighthouse_lossless.mp4 -v warning -f yuv4mpegpipe - | x265 --bitrate %b --y4m - --qg-size 64 --preset veryslow --psnr --ssim --hevc-aq ah-%b-1.hevc --pass 1
ffmpeg -i ../lighthouse_lossless.mp4 -v warning -f yuv4mpegpipe - | x265 --bitrate %b --y4m - --qg-size 64 --preset veryslow --psnr --ssim --hevc-aq ah-%b-2.hevc --pass 2
)

Results (sorted by PSNR):
bitrate 750:
aq-mode 1 - PSNR 43.244, SSIM 15.697 dB
aq-mode 3 - PSNR 43.063, SSIM 15.549 dB
aq-mode 2 - PSNR 42.919, SSIM 15.451 dB
--hevc-aq -- PSNR 42.514, SSIM 14.240 dB
aq-mode 0 - PSNR 41.108, SSIM 13.925 dB

bitrate 1500:
aq-mode 1 - PSNR 45.388, SSIM 17.483 dB
aq-mode 3 - PSNR 45.283, SSIM 17.366 dB
aq-mode 2 - PSNR 45.172, SSIM 17.288 dB
--hevc-aq -- PSNR 44.372, SSIM 15.980 dB
aq-mode 0 - PSNR 43.491, SSIM 16.001 dB

bitrate 3000:
aq-mode 3 - PSNR 47.310, SSIM 18.908 dB
aq-mode 2 - PSNR 47.276, SSIM 18.872 dB
aq-mode 1 - PSNR 47.240, SSIM 18.869 dB
--hevc-aq -- PSNR 46.424, SSIM 17.772 dB
aq-mode 0 - PSNR 46.084, SSIM 18.084 dB

bitrate 6000:
aq-mode 2 - PSNR 48.800, SSIM 19.839 dB
aq-mode 3 - PSNR 48.661, SSIM 19.710 dB
aq-mode 0 - PSNR 48.384, SSIM 19.659 dB
aq-mode 1 - PSNR 48.268, SSIM 19.436 dB
--hevc-aq -- PSNR 48.093, SSIM 19.248 dB

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

Full results in attached screen.txt

[Selur]

It's funny like aq-mode 1 wins at small bitrates and looses at high (even with aq-mode 0).
which makes it strange that aq-mode 2 is the new default,... (https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6)

[Forteen88]

@Ma. Isn't SSIM a better image-quality metric?
And isn't VMAF the best image-quality metric?! I saw that someone here shared a VMAF-version of x265.

[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]

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 ?

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/12/31/dc8f90ba1323839e80650471dc566510.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]

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

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 (https://dropmefiles.com/Dpar2).

[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]

x265-3.0_RC+2-5251075203e1-win64-static+shared [ICC 1900] (https://drive.google.com/open?id=1xZQABtoaSFgGu11YstmHKYLzO3elemlC)

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]

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]

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]

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]

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.php?p=1861429#post1861429

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

[Ma]

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 (https://dropmefiles.com/Dpar2).

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]

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! :goodpost:

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]

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]

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]

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]

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]

Wonderful! :goodpost:

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]

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! :)

[jlpsvk]

Wonderful! :goodpost:

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]

Is this 'video only' sample (supplied by algorithm_colon) what you're looking for: https://forum.doom9.org/showthread.php?p=1861429#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 (https://www.mediafire.com/file/l6e0rrj4q1c2r3c/) (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]

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