x265 3.0 Dolby Vision encoding

[kabelbrand]

Did someone manage to get an encode up and running with the new --dolby-vision-rpu option?

This is what the command line looks so far:
ffmpeg -loglevel quiet -i Cosmos_Laundromat_Dolby_Vision_24p_2048x858.mxf (http://download.opencontent.netflix.com/?prefix=TechblogAssets/CosmosLaundromat/Cosmos_Laundromat_Dolby_Vision_24p_2048x858_LtRt_IMF/) -pix_fmt yuv420p10 -f rawvideo - | x265-10b - --input-res 2048x858 --input-depth 10 --input-csp i420 --fps 24/1 --profile main10 --level-idc 5.1 --bitrate 30000 --vbv-maxrate 40000 --vbv-bufsize 40000 --repeat-headers --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) --max-cll 1000,400 --dolby-vision-profile 8.1 --dolby-vision-rpu cosmos_laundromat_vdm_hdr_p3d65_pq_20160525_01_2048x858_dovi_4000nit_metadata.xml (http://download.opencontent.netflix.com/?prefix=TechblogAssets/CosmosLaundromat/cosmos_laundromat_vdm_hdr_p3d65_pq_20160525_01_2048x858/vdm/hdr/p3d65_pq/20160525_01/metadata/) --output Cosmos_Laundromat_Dolby_Vision_24p_2048x858.265

Is there something wrong with the metadata? I always get this error:
x265 [error]: Invalid Dolby Vision RPU startcode in POC 0

Thanks.

[nevcairiel]

Judging from the error, it wants a binary encoded RPU file, and not a metadata XML.

[kabelbrand]

Judging from the error, it wants a binary encoded RPU file, and not a metadata XML.
Thanks, it's plain XML indeed. So how do I get a binary presentation of this? "metafier" does not seem to support it.

Btw. the source assets are linked in the command line.

[Selur]

Would be interested in that too.
Also is there a way to extract the data somehow?

As a side note: does using
--master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) --max-cll 1000,400
make sense here?
I thought those were HDR-10 settings and shouldn't be used with Dolby Vision.

Cu Selur

[kabelbrand]

I thought those were HDR-10 settings and shouldn't be used with Dolby Vision.
I guess when aiming for Dolby Vision profile 8.1 these should be included to also have HDR10 playback compatibility:
http://x265.org/x265-delivers-dolby-vision-streams/

[Selur]

Ah didn't know that. :)

[halls]

Hi!

There is any way to extract metadata from an existing file into RPU file?

[benwaggoner]

I guess when aiming for Dolby Vision profile 8.1 these should be included to also have HDR10 playback compatibility:
http://x265.org/x265-delivers-dolby-vision-streams/
Yes, you should include the 2086 metadata if you want to use it. A device that can't use the 8.1 DoVi metadata will fall back to HDR-10 static metadata (or HDR10+ dynamic metadata if available and supported)

[djloewen]

Am I correct in understanding that there's currently no way to extract the RPU information from the secondary Dolby Vision HEVC track on a commercially-produced UHD Blu-Ray, and use that data to encode in X.265?

[Blue_MiSfit]

I don't believe there is, at least not publicly available.

Also, it's x265 not X.265 :)

[djloewen]

Got it, thanks :).

[nghiabeo20]

Yes, you should include the 2086 metadata if you want to use it. A device that can't use the 8.1 DoVi metadata will fall back to HDR-10 static metadata (or HDR10+ dynamic metadata if available and supported)

Does DoVi file encoded with previous version of x265 (specifically 2.5) still has this fallback capability? Thanks!

[benwaggoner]

Does DoVi file encoded with previous version of x265 (specifically 2.5) still has this fallback capability? Thanks!
It should, but I've never tried.

[Balling]

>or HDR10+ dynamic metadata if available and supported

Actually HDR10+ is preferred usually.

[benwaggoner]

>or HDR10+ dynamic metadata if available and supported

Actually HDR10+ is preferred usually.
Yeah, anything that supports Profile 8.1 or HDR10+ will use one of those before falling back to using the (pretty lame and vestigial) 2086 static metadata.

I don't know of any devices that have shipped with BOTH DoVi 8.1 and HDR10+, and it would be up to the device to pick which one to use if both are available. I don't know if there would be any practical advantage of one over the other. DoVi Profile 5 can, in theory, provide less banding and somewhat more efficiency due to its non-backwards compatible base layer and YCtCp. I've not tested that myself yet, though. It's be a pain to evaluate without a single display that can use both modes. Probably feasible with a couple of reference displays driven by a ColorFront Transcoder...

[Stacey Spears]

Thanks, it's plain XML indeed. So how do I get a binary presentation of this? "metafier" does not seem to support it.

Btw. the source assets are linked in the command line.

Dolby Encoding Engine is available for $500 per year per node and can create a binary RPU from a Dolby Vision XML.

[Blue_MiSfit]

Dolby Encoding Engine is available for $500 per year per node and can create a binary RPU from a Dolby Vision XML.

DEE is a solid tool. I've used this for several projects using Dolby tech.

[quietvoid]

Posting in this thread as it's the oldest.

I made a first release of my tool: https://github.com/quietvoid/dovi_tool/releases/tag/0.1.0-fix
It can be used to create an RPU file from a profile 5, 7 or 8 HEVC encoded file.

Commands:
demux: Demuxes single track dual layer Dolby Vision into Base layer and Enhancement layer files.
extract-rpu: Extracts Dolby Vision RPU from an HEVC encoded file.

More info in the README.
Enjoy.

[ghostshadow]

Hello Quietvoid, thank you for your work
I used it on an El.hevc file containing the RPU and I have this error message
thread 'main' has overflowed its stack

[quietvoid]

It might be related to the memory, buffer allocations..
My stack size on linux was limited to 8MB, and I was using 4MB in the code.
I have lowered it way down, please try again.

[ghostshadow]

It might be related to the memory, buffer allocations..
My stack size on linux was limited to 8MB, and I was using 4MB in the code.
I have lowered it way down, please try again.

Hello quietvoid, it's good it works, that was it.
Now I'm going to try encoded in x265 and give it this rpu as a parameter. I will let you know

[imhh11]

@quietvoid thanks a lot for your tool. Just for fun, I tried to encode p7 dual-layer bluray to p5 single layer full range. Seems to work well on my bluray player and Nvidia Shield but I don't know if I used proper x265.exe settings.
But I probably should use profile 8 and keep the BL HDR10 compatible.

P5 encoded sample:
https://drive.google.com/file/d/12Cm485kF2dmBrXdkniuWkRcKCG7VYZ1X/view?usp=sharing

P8 encoded sample:
https://drive.google.com/file/d/1HSe69M6q74tpyXzX4qrqnUZDRVz6Q8k1/view?usp=sharing

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU
Codec ID : dvhe
Codec ID/Info : High Efficiency Video Coding with Dolby Vision
Duration : 1 min 0 s
Bit rate : 8 440 kb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 0)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.042
Stream size : 61.2 MiB (100%)
Writing library : x265 3.4+26-ga82c6c7a7:[Windows][GCC 10.2.1][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=28 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=1459 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-2:-2 / no-sao / no-sao-non-deblock / rd=3 / selective-sao=0 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=3 / rc=crf / crf=14.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=1 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default : No
Encoded date : UTC 2020-11-24 00:29:30
Tagged date : UTC 2020-11-24 00:29:30
Color range : Full
Codec configuration box : hvcC+dvcC


Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU / SMPTE ST 2086, HDR10 compatible
Codec ID : dvhe
Codec ID/Info : High Efficiency Video Coding with Dolby Vision
Duration : 1 min 0 s
Bit rate : 6 795 kb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.034
Stream size : 49.3 MiB (100%)
Writing library : x265 3.4+26-ga82c6c7a7:[Windows][GCC 10.2.1][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=28 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=1459 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-2:-2 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=14.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) / cll=233,63 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default : No
Encoded date : UTC 2020-11-24 01:57:43
Tagged date : UTC 2020-11-24 01:57:43
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 233 cd/m2
Maximum Frame-Average Light Level : 63 cd/m2
Codec configuration box : hvcC+dvcC

[quietvoid]

I'm not sure BT2020 primaries is meant to be played as profile 5 :P
They both play just fine on my device, otherwise.
But yes, the profile 5 only plays in Dolby Vision.

[imhh11]

yes you're right, it's probably not possible yet to encode p7 bt2020 to true p5 which uses a different colorspace. or maybe you know how ?
profile 8 file with HDR10 BL should be standard though

thank's again for your great work.

[quietvoid]

There still seem to be unknowns in Dolby's IPTQc2 colorspace, if you're interested this mpv issue has good info: https://github.com/mpv-player/mpv/issues/7326

[SeeMoreDigital]

I'm not sure BT2020 primaries is meant to be played as profile 5 :P
They both play just fine on my device, otherwise.
But yes, the profile 5 only plays in Dolby Vision.Both files display the Dolby Vision logo on my 2016 LG television...

[ghostshadow]

Both files display the Dolby Vision logo on my 2016 LG television...

Hello SeeMoreDigital, your encodings are in mp4, have you tried in mkv?

thank you again to quietvoid after the hdr10 + it finds the solution of the dolby vision :thanks:

[imhh11]

Hello SeeMoreDigital, your encodings are in mp4, have you tried in mkv?

thank you again to quietvoid after the hdr10 + it finds the solution of the dolby vision :thanks:

x265.exe produces raw HEVC stream. not an mp4 nor an mkv.

To create those samples, I encoded with x265.exe and then I used the mp4muxer to create a DV MP4. You could also use the nightly tsMuxer (https://bintray.com/justdan96/tsMuxer/tsMuxerGUI-Nightly#files) and make a TS file with Atmos and maybe you can try the yusesope (https://www.makemkv.com/forum/memberlist.php?mode=viewprofile&u=28431&sid=d946a69ba018aa4839a5ec207500f5f7) tool (mkv patcher ?) but I have minimal experience with his tool.

[ghostshadow]

x265.exe produces raw HEVC stream. not an mp4 nor an mkv.

To create those samples, I encoded with x265.exe and then I used the mp4muxer to create a DV MP4. You could also use the nightly tsMuxer (https://bintray.com/justdan96/tsMuxer/tsMuxerGUI-Nightly#files) and make a TS file with Atmos and maybe you can try the yusesope (https://www.makemkv.com/forum/memberlist.php?mode=viewprofile&u=28431&sid=d946a69ba018aa4839a5ec207500f5f7) tool (mkv patcher ?) but I have minimal experience with his tool.

no I encode in x265 and then with mkvtoolnix

[imhh11]

no I encode in x265 and then with mkvtoolnix

someone correct me if I'm wrong but mkvtoolnix has been updated to support dual-layer profile 7 Dolby Vision remixing(only the file created by makemkv) and does not support single layer DV remuxing.

[ghostshadow]

After you have to go back to Makemkv that's all

[SeeMoreDigital]

Hello SeeMoreDigital, your encodings are in mp4, have you tried in mkv?Playing Dolby Vision HEVC encoded video streams placed within the .mkv container on an LG television is currently not possible because an entirely new .mkv file parser and splitter will have to be created first.

The same goes for any other SoC hardware playback device...

[imhh11]

After you have to go back to Makemkv that's all

I'm curious, how do you do that? I know it works with dual layers files but I never heard of MakeMkv working with single-layer file
I just tried and the DV metadata are gone once the new MKV is created.

[theweasley]

Posting in this thread as it's the oldest.

I made a first release of my tool: https://github.com/quietvoid/dovi_tool/releases/tag/0.1.0-fix
It can be used to create an RPU file from a profile 5, 7 or 8 HEVC encoded file.

Commands:
demux: Demuxes single track dual layer Dolby Vision into Base layer and Enhancement layer files.
extract-rpu: Extracts Dolby Vision RPU from an HEVC encoded file.

More info in the README.
Enjoy.

Thank you this is a Great tool! Works really well. I've managed to successfully create a profile 8.1 x265 uncropped encode with it.

I have a quick question on cropping.

I'd like to crop the encode as well. Looking at these specific lines in vdr_dm_data.rs (https://github.com/quietvoid/dovi_tool/blob/4fe944a949e2109c22b6ad0e64b01ea652f03f4e/src/dovi/rpu/vdr_dm_data.rs#L309-L310)

Am I right to assume that the active area for DV can be altered here by hard coding it into the RPU / EL to get a properly cropped encode with DV? Been experimenting with it a bit and I'm having trouble figuring out how the values can be altered. Can I simply hardcode a custom offset here and if so what would be the correct way to input them?

Once again, thank you very much for the script. Works amazingly. And your insight would be most appreciated! :)

[quietvoid]

From what I understand, they are only necessary to tell the decoder how large the black bars are.
If you crop them off, it would probably be 0.

[theweasley]

From what I understand, they are only necessary to tell the decoder how large the black bars are.
If you crop them off, it would probably be 0.
Oh I see that makes more sense. Thanks! I'll test and report back.

One more quick thing: I've noticed that if I build your script from the source (without changing anything in the code), the dovi parsing runs super slow with a simple ffmpeg stream copy to EL.hevc, like at 0.5x even. But when I use your prebuilt tool that you release on github, it's 10 times faster. I am probably building it wrong. I use cargo build on the src directory. Should I be doing something else?

[quietvoid]

You need to build with optimizations, usually "cargo build --release".

[theweasley]

You need to build with optimizations, usually "cargo build --release".
Amazing! Both your suggestions worked. Setting it to 0 allowed me to create a cropped encode that works without issues and the optimized build fixed the slow EL extraction. Without your tool this wouldn't be possible! Thanks again :)

[telemO]

Amazing! Both your suggestions worked. Setting it to 0 allowed me to create a cropped encode that works without issues and the optimized build fixed the slow EL extraction. Without your tool this wouldn't be possible! Thanks again :)
Yes, quietvoid is the man !
He's developped this excellent and useful tool for the community, as well as the one to parse the HDR10+ metadata : :thanks: so much for that.

@theweasley: I am very interesting to know how to transcode cropped version with the DoVi tool : are you changing the code of this DV tool? Or just inputing some extra parameters when parsing?
@quietvoid : Is it possible to transcode cropped video as well with your HDR10+ tool?

Thank you very much in advance for answering

[quietvoid]

There's no simple way to use the tool for cropped video, you have to edit the code.

Also, using the RPU with x265 to transcode might end up with some desyncs due to the way x265 is inserting the metadata back.
Unfortunately I don't think there is a solution for that, other than inserting the metadata after transcoding.
See https://github.com/quietvoid/dovi_tool/issues/9#issuecomment-803652617

Now those desyncs are not always visible in playback, but they're still there.

For HDR10+ the same desync issue is present. For cropped video, the metadata is supposedly resolution agnostic and hopefully the analysis is done on the active image area only.
So it should work in theory,

I'm curious to know how streaming services make use of x265's RPU insertion. There has to be some predicting the transcode's decoding order somehow, to make sure the RPU is synced throughout.
Though I've had artifacts with Dolby Vision on Netflix as well, so maybe they don't bother syncing either.

[telemO]

Thanks a lot, dear quietvoid, for having replied quickly to me.
I'm trying again to post you a reply - few days after my first attempt failed (supposedly due to moderation filtering?)

There's no simple way to use the tool for cropped video, you have to edit the code.
Erf... That is a matter for me: I'm not competent in programming neither compiling (and a bit allergic to it actually).
Is it abusive to ask you, theweasley or anyone else able to compile with this cargo thing, a "crop able" version of your DoVi tool?

Also, using the RPU with x265 to transcode might end up with some desyncs due to the way x265 is inserting the metadata back.
See https://github.com/quietvoid/dovi_tool/issues/9#issuecomment-803652617
I'm also having similar issues as your topic above, with "red flash" insertion before a fade out during the start credits (I'm working with a 2600 frames extract of a movie remux).
I've also detected a magenta flash on a white area (a reflection zone) during a real movie part.

Unfortunately I don't think there is a solution for that, other than inserting the metadata after transcoding.
What do you mean by that exactly ?
To mux it with the yusesope tool or via mkvmerge + MakeMKV ? But how would you mux a RPU.bin with an hevc file ?

For HDR10+ the same desync issue is present.
For cropped video, the metadata is supposedly resolution agnostic and hopefully the analysis is done on the active image area only.
So it should work in theory,
From an article I found about Metadata Levels on the Dolby Professional Support Knowledge (https://professionalsupport.dolby.com/s/article/Dolby-Vision-Metadata-Levels?language=en_US), it is written "Ratio of canvas and image (active area)" as part of the Level 0.
This would mean the same as you mentionned for the HDR10+ theorical implementation, on the active area... and therefore no need to have a "crop-able" version?

I'm curious to know how streaming services make use of x265's RPU insertion. There has to be some predicting the transcode's decoding order somehow, to make sure the RPU is synced throughout.
Though I've had artifacts with Dolby Vision on Netflix as well, so maybe they don't bother syncing either.
Probably someone knowledgeable in the video streaming domain, such as benwaggoner, would give you answer or at least some hints.

[quietvoid]

What do you mean by that exactly ?
To mux it with the yusesope tool or via mkvmerge + MakeMKV ? But how would you mux a RPU.bin with an hevc file ?
I mean parsing the final HEVC and interleaving the metadata NAL units directly, it's still a raw bitstream.
Implies correctly decoding the frames in the right order though.

This would mean the same as you mentionned for the HDR10+ theorical implementation, on the active area... and therefore no need to have a "crop-able" version?
Analysis for both metadata should be assumed to be done on the active area only, according to docs.
The only difference with Dolby Vision is that the active area is also present in the final metadata, while it's not in HDR10+.

As for a "croppable" version, I just have a Windows binary: https://mega.nz/file/dZ1mXQga#ve0DwlCbgNHKkA8YbiM9VAHK5_UI-HweAXRg-BEXG7U
Maybe this is a feature I can add, since a lot of people have asked for it..

[telemO]

quietvoid, you're the boss, man !
You're again replying quickly, and with a "croppable" release of your tool under Windows, perfectly suitable with my need as an end-user encoder.
I'm gonna try this within the coming days and let you know my result, as soon as possible, as I think I have a good sample to know if this croppable option would work.

I have to see how and where to share some samples for the community to test and tell about the syncs / artifacts issues.
And then to share my experience for the others to be able to do the same, as for the HDR10+ case.

[telemO]

As for a "croppable" version, I just have a Windows binary: https://mega.nz/file/dZ1mXQga#ve0DwlCbgNHKkA8YbiM9VAHK5_UI-HweAXRg-BEXG7U
Maybe this is a feature I can add, since a lot of people have asked for it..
Thanks a lot again for delivering so quickly this croppable version, and of course, I would encourage you to publish an updated version of the dovi_tool with this feature, whenever you've get the time to do it.

As mentionned before, a first return on the sample I tought about testing cropping:

cropped at 1632 instead of original 2160p, which is a FEL DoVi UHD-BD base material,
transcoded with x265 v3.4 Mod version from Staxrip 2.1.7.0 in DV profile 8.1, inputing the RPU converted to 8.1 by the quietvoid's dovi_tool,
encapsuled as a MP4 file, with mp4muxer, in order to test with the internal player of my Panasonic TV,

the DoVi logo is showing on as well as the picture menus and parameters related to it are activated (such as Dolby IQ):

with the RPU extracted by the github version 0.1.2 of dovi_tool, the TV displays the cropped sample with black bars lapping over the 1632-high area, i.e. it is like "over-cropping" the already cropped picture.
with the RPU extracted by the unofficial "crop-able" version of dovi_tool, the TV displays the cropped sample with black bars as expected.

To mitigate this test case, I tried with another DoVi FEL UHD-BD base material, and whatever I use the "crop-able" or not version of dovi_tool, both of my cropped test samples are displayed correctly the same by my TV.
I deduce that the metadata where containing some information of an higher area on the first sample material and not on this other one.

I'm now thinking that I read something about subtitles mattering, and that I should have a look at the consequences of cropping for diplaying these.


For information about artifact or sync pbs, I also notice a "red flashy" insertion on a text animation just before a fade out (as for the first sample).
I've tried many x265 parameters change, such as chromaloc=0 or 2, ref=6 (as you mentionned), scenecut=0, hrd-concat, no-open-gop, uhd-bd : none of these solved the issues.

[quietvoid]

I just released 0.2.0 with metadata reordering according to the frames display output order instead of decoded order.
As well as adding the --crop flag for setting active area offsets to zero.

[telemO]

I just released 0.2.0 with metadata reordering according to the frames display output order instead of decoded order.
As well as adding the --crop flag for setting active area offsets to zero.
Thanks a lot again for taking your time to update and improve the tool.

I'll have to test if this new parsing method removes the artifact/sync issues I've noticed on my test sample.

Few questions to you, quietvoid :
- I'm confused for some time now with the convert option FEL to MEL: what is the use case? To encode in DV profile 5 ?
- What is the use case(s) of the new command "inject-rpu"? Would it mean that I can inject the RPU into my transcoded hevc file afterwards and not during the x265 process anymore (with the --dolby-vision-rpu command)?

[quietvoid]

- I'm confused for some time now with the convert option FEL to MEL: what is the use case? To encode in DV profile 5 ?No, the profile 7 stays except compatibility is better for devices that cannot play FEL files.

- What is the use case(s) of the new command "inject-rpu"? Would it mean that I can inject the RPU into my transcoded hevc file afterwards and not during the x265 process anymore (with the --dolby-vision-rpu command)?It's still experimental, but the basic of it is to be able to add Dolby Vision metadata to an existing HDR10 file.
However I'd still suggest using the RPU with x265 instead.
YMMV.

[telemO]

I made a test with one of my samples that was displaying artifacts, i.e. wrong color inserts ("flashes") in some areas : there are all gone with your last tool revision.
Wonderful !!! :thanks:
I still have to test with another sample that such artifacts are gone as well, and then I'll become very confident using your parsing tool (which I did use anyway to share already some content in DoVi 8.1)

No, the profile 7 stays except compatibility is better for devices that cannot play FEL files.
Am I understanding correctly that the file will still be made of BL+FEL as profile 7 but the FEL will contain an MEL type RPU so that the devices which cannot handle FEL would decode in MEL mode?

It's still experimental, but the basic of it is to be able to add Dolby Vision metadata to an existing HDR10 file.
However I'd still suggest using the RPU with x265 instead.
YMMV.
Oh, that would be great ! I don't have the time to test in the coming weeks to make some mileage but it would worth some tries.

[quietvoid]

Am I understanding correctly that the file will still be made of BL+FEL as profile 7 but the FEL will contain an MEL type RPU so that the devices which cannot handle FEL would decode in MEL mode?

Yes that's how it should work.

[Lucius Snow]

Hi all,

Is there a way to convert plain-text XML (from DaVinci) to binary RPU file metadatas without using the expensive Dolby Encoding Engine software?

Or maybe a way to convert a JSON file from HDR10+ to this binary RPU?

Thanks.