x265 and Dolby Vision

[ghostshadow]

Hello, is it possible today to encode a UHD Dolby vision in x265?
If so, I would like to know the method.
I tried by extracting the 2 Dolby layers (BL + EL).
The BL being the main layer with the video and the EL mainly containing the specific dolby meta if I understood (afterwards I only had a Dolby UHD available).
I tested by encoding the BL layer and giving the dolby-vision-rpu the EL file.
- it does not work rpu non-compliant.
I tested without dolby-vision-rpu.
-it does not work.
I tested by 'merging' the BL + EL with the 'yusesope' method and encoding this track BL_EL.hevc without dolby-vision-rpu.
-it does not work. Mistake :
x265 [error]: x265_encoder_open () failed for Enc,

aborted at input frame 1, output frame 0 in x265

So we have to do a mkv remux of the UHD dolby vision, then extract the video track (as usual when we do standard hdr versions), and encode this video track by specifying just the –dolby-vision-profile?
thank you in advance

[SeeMoreDigital]

I don't know if this is going to help you. But after backing-up the Dolby Vision version of 'The Fifth Element', I noticed the following 'Encode Settings: -

General
ID : 1 (0x1)
Complete name : \\SYNOLOGY_NAS\My HD Movies\UHD Movies\The Fifth Element [1997] 206mins (78.4GB)\AVCHD\BDMV\STREAM\00000.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 78.4 GiB
Duration : 2 h 6 min
Overall bit rate mode : Variable
Overall bit rate : 88.9 Mb/s
Maximum Overall bit rate : 35.5 Mb/s

Video #1
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 6 min
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
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

Video #2
ID : 4117 (0x1015)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 6 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Writing library : x265 3.2+20-a4e060a44839:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=16,16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 /
input-res=1920x1080 / interlace=0 / total-frames=3854 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd /
info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / gop-lookahead=0 / bframes=3 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=24 /
lookahead-slices=6 / 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 /
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=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / 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=0 / rc=cbr / bitrate=500 / qcomp=0.60 / qpstep=4 /
stats-write=0 / stats-read=0 / vbv-maxrate=500 / vbv-bufsize=550 / vbv-init=0.9 / 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=1 / 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=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.01 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 /
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-qp
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

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3 MLP FBA 16-ch
Format/Info : Audio Coding 3 + Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 2 h 6 min
Bit rate mode : Variable
Bit rate : 640 kb/s
Maximum bit rate : 6 342 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 578 MiB (1%)
Service kind : Complete Main
Number of dynamic objects : 11
Bed channel count : 1 channel
Bed channel configuration : LFE

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 2 h 6 min
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 578 MiB (1%)
Service kind : Complete Main

Text
ID : 4768 (0x12A0)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144


Cheers

[benwaggoner]

Hello, is it possible today to encode a UHD Dolby vision in x265?
If so, I would like to know the method.
I tried by extracting the 2 Dolby layers (BL + EL).
The BL being the main layer with the video and the EL mainly containing the specific dolby meta if I understood (afterwards I only had a Dolby UHD available).
I tested by encoding the BL layer and giving the dolby-vision-rpu the EL file.
- it does not work rpu non-compliant.
I tested without dolby-vision-rpu.
-it does not work.
I tested by 'merging' the BL + EL with the 'yusesope' method and encoding this track BL_EL.hevc without dolby-vision-rpu.
-it does not work. Mistake :
x265 [error]: x265_encoder_open () failed for Enc,

aborted at input frame 1, output frame 0 in x265

So we have to do a mkv remux of the UHD dolby vision, then extract the video track (as usual when we do standard hdr versions), and encode this video track by specifying just the –dolby-vision-profile?
thank you in advance
Yes, x265 absolutely supports encoding Dolby Vision, but only the single-layer Profiles 5, 8.1, and 8.2. So not the dual layer profiles. Profile 5 encodes the same quality at about 20% lower bitrate than dual layer, so that's what everyone is using today for offline playback unless they NEED the SDR backwards compatibility for some reason. Profile 8.x is targeted for live and not supported by all older Dolby Vision players. Profile 8.1 is an HDR-10 base layer plus metadata, ala HDR10+, so has good backwards compatibility.

These are the relevant command line parameters:

--dolby-vision-profile <integer|float>
Generate bitstreams confirming to the specified Dolby Vision profile, note that 0x7C01 makes RPU appear to be an unspecified NAL type in HEVC stream. If BL is backward compatible, Dolby Vision single layer VES will be equivalent to a backward compatible BL VES on legacy device as RPU will be ignored.

The value is specified as a float or as an integer with the profile times 10, for example profile 5 is specified as “5” or “5.0” or “50”.

Currently only profile 5, profile 8.1 and profile 8.2 enabled, Default 0 (disabled)


--dolby-vision-rpu <filename>
File containing Dolby Vision RPU metadata. If given, x265’s Dolby Vision metadata parser will fill the RPU field of input pictures with the metadata read from the file. The library will interleave access units with RPUs in the bitstream. Default NULL (disabled).

CLI ONLY


And for Profile 8.


--dhdr10-info <filename>
Inserts tone mapping information as an SEI message. It takes as input, the path to the JSON file containing the Creative Intent Metadata to be encoded as Dynamic Tone Mapping into the bitstream.

Click here for the syntax of the metadata file. A sample JSON file is available in the downloads page


--dhdr10-opt, --no-dhdr10-opt
Limits the frames for which tone mapping information is inserted as SEI message. Inserts SEI only for IDR frames and for frames where tone mapping information has changed.

[SeeMoreDigital]

Yes, x265 absolutely supports encoding Dolby Vision, but only the single-layer Profiles 5, 8.1, and 8.2. So not the dual layer profiles. Profile 5 encodes the same quality at about 20% lower bitrate than dual layer, so that's what everyone is using today for offline playback unless they NEED the SDR backwards compatibility for some reason. Profile 8.x is targeted for live and not supported by all older Dolby Vision players. Profile 8.1 is an HDR-10 base layer plus metadata, ala HDR10+, so has good backwards compatibility.

I'm confused...

According to the MediaInfo report I posted above, the 'dual-layer' element of the Dolby Vision file was encoded using x265 3.2+20-a4e060a44839:[Windows][GCC 6.3.0][64 bit] 10bit.


Cheers

[ghostshadow]

Yes, x265 absolutely supports encoding Dolby Vision, but only the single-layer Profiles 5, 8.1, and 8.2. So not the dual layer profiles. Profile 5 encodes the same quality at about 20% lower bitrate than dual layer, so that's what everyone is using today for offline playback unless they NEED the SDR backwards compatibility for some reason. Profile 8.x is targeted for live and not supported by all older Dolby Vision players. Profile 8.1 is an HDR-10 base layer plus metadata, ala HDR10+, so has good backwards compatibility.



Ok thank,so if I understand correctly you should preferably use profile 5.
So to do things right from a UHD Blu-ray: you have to make a backup with MakeMKV by combining the two original video tracks into one track.
Then we encode this video track in x265 (BL + EL + RPU). ?

--dolby-vision-rpu <filename>
File containing Dolby Vision RPU metadata. If given, x265’s Dolby Vision metadata parser will fill the RPU field of input pictures with the metadata read from the file. The library will interleave access units with RPUs in the bitstream. Default NULL (disabled).

I thought we couldn't extract the rpu metadata into a binary file
Personally I tested Davinci Resolve, I was able to create a Trim Dolby vision meta file but it is in xml and given what is in it I doubt that it is the dynamic dolby vision data, there may be too much. .

[SeeMoreDigital]

Another dual-layer Dolby Vision example with both layers encoded using x265: -

General
ID : 0 (0x0)
Complete name : E:\Dolby Vision Tests [Temp]\StudioCanal Dolby Vision Test\00004.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 209 MiB
Duration : 20 s 725 ms
Overall bit rate mode : Variable
Overall bit rate : 84.7 Mb/s
Maximum Overall bit rate : 109 Mb/s

Video #1
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 20 s 41 ms
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Writing library : x265 3.2+20-a4e060a44839:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=6 / numa-pools=16,16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 /
input-res=3840x2160 / interlace=0 / total-frames=481 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=5 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd /
info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / gop-lookahead=0 / bframes=3 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=24 /
lookahead-slices=0 / scenecut=10 / hist-scenecut=0 / radl=0 / splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=3 /
tu-intra-depth=3 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / tskip / nr-intra=0 / nr-inter=0 / constrained-intra / no-strong-intra-smoothing /
max-merge=5 / limit-refs=0 / no-limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics / deblock=-2:-2 /
no-sao / no-sao-non-deblock / rd=6 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 /
psy-rd=5.00 / psy-rdoq=50.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=78000 / qcomp=0.60 / qpstep=4 / stats-write=1 / stats-read=0 /
slow-firstpass / vbv-maxrate=82000 / vbv-bufsize=99000 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr /
qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / 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=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.01 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / 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-qp
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

Video #2
ID : 4117 (0x1015)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 20 s 41 ms
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Writing library : x265 3.2+20-a4e060a44839:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=16,16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 /
input-res=1920x1080 / interlace=0 / total-frames=481 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd /
info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / gop-lookahead=0 / bframes=3 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=24 /
lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / 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 / 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=0:0 /
sao / no-sao-non-deblock / rd=4 / selective-sao=4 / 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=cbr / bitrate=500 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 /
vbv-maxrate=500 / vbv-bufsize=550 / vbv-init=0.9 / 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=1 / 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=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.01 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / 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-qp
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

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Muxing mode : Stream extension
Codec ID : 131
Duration : 20 s 42 ms
Bit rate mode : Variable
Bit rate : 640 kb/s
Maximum bit rate : 4 341 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 1.53 MiB (1%)
Service kind : Complete Main

Text
ID : 4768 (0x12A0)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Delay relative to video : 83 ms

[benwaggoner]

I'm confused...

According to the MediaInfo report I posted above, the 'dual-layer' element of the Dolby Vision file was encoded using x265 3.2+20-a4e060a44839:[Windows][GCC 6.3.0][64 bit] 10bit.

It is certainly possible to use x265 to encode the two layers, like you can encode anything. x265 just doesn't have built in support, so other operations in other software needs to be performed before and after.

[benwaggoner]

Ok thank,so if I understand correctly you should preferably use profile 5.
So to do things right from a UHD Blu-ray: you have to make a backup with MakeMKV by combining the two original video tracks into one track.
Then we encode this video track in x265 (BL + EL + RPU). ?
That wouldn't be Profile 5, which doesn't have a video enhancement layer, just a metadata one. You'd need tools from Dolby or that have licensed a Dolby SDK to convert from dual layer to Profile 5.

I thought we couldn't extract the rpu metadata into a binary file
Personally I tested Davinci Resolve, I was able to create a Trim Dolby vision meta file but it is in xml and given what is in it I doubt that it is the dynamic dolby vision data, there may be too much. .
How big was it?

[SeeMoreDigital]

And just to confuse matters further. There are two different enhancement layers.

MEL = 10-bit minimal enhancement layer (encoded at 2Mbps or below)
FEL = 12-bit full enhancement layer (encoded at 3Mbps or much, much higher)

---------------------------------------------------------------------------------------------

Edit: And for anyone who's not tried it yet...

When you re-mux the secondary (1920x1080) Dolby Vision HEVC video stream/layer into either the .mkv or .m2ts container and play it in either a software player or hardware playback device. A MEL encoded video stream looks like this:

https://i.ibb.co/q09CcP5/Fifth-Element-MEL-mkv-snapshot-00-55-46-2020-10-04-18-37-10.jpg

...but a FEL encoded video stream looks like this:

https://i.ibb.co/zV9xFkj/Forest-Gump-FEL-mkv-snapshot.jpg


Cheers

[ghostshadow]

i used yusesope tools to combine the Bl + the El into one. After I made an iso with TsMuxer, then I extracted the x265 to encode it

for the rpu Trim Dolby vision 7 ko for the xml

[benwaggoner]

i used yusesope tools to combine the Bl + the El into one. After I made an iso with TsMuxer, then I extracted the x265 to encode it

for the rpu Trim Dolby vision 7 ko for the xml
That looks like the data for a single dynamic metadata state, used for one or a few frames. Not for an entire title.

[ghostshadow]

That looks like the data for a single dynamic metadata state, used for one or a few frames. Not for an entire title.

thanks, that's what seemed to me. I must not use DavinciResolve well
It is certainly possible to use x265 to encode the two layers, like you can encode anything. x265 just doesn't have built in support, so other operations in other software needs to be performed before and after.
process yusesope :
ffmpeg -i path\to\the\file.m2ts -ss 0 -t 120 -map 0:0 -c copy path\to\BL.hevc
ffmpeg -i path\to\the\file.m2ts -ss 0 -t 120 -map 0:1 -c copy path\to\EL.hevc

Using tool python yusesope, double click on the MUX_AND_CONVERT_TO_MEL.bat file and follow the instructions on the screen.
You will get a BL_EL_RPU.hevc file
Create a TS file using the BL_EL_RPU.hevc file and TsMuxeR
for mp4 using mp4muxer

[ghostshadow]

I don't know if this is going to help you. But after backing-up the Dolby Vision version of 'The Fifth Element', I noticed the following 'Encode Settings: -




Cheers

thanks SeeMoreDigital. What did you back up with? (dvdfab, MakeMKV?)

Another dual-layer Dolby Vision example with both layers encoded using x265: -
he two video tracks are encoded. I don't quite understand. I thought there was only the base layer to encode.

[benwaggoner]

he two video tracks are encoded. I don't quite understand. I thought there was only the base layer to encode.
For Profile 5 and Profile 8.1, there is a base layer and a metadata layer without any video bitstream.

The older two layer profiles used a base layer and an enhancement layer combining both a video bitstream and metadata.

[SeeMoreDigital]

thanks SeeMoreDigital. What did you back up with? (dvdfab, MakeMKV?)MakeMKV using its (full disc) 'Backup' option...

[ghostshadow]

MakeMKV using its (full disc) 'Backup' option...


I am using MakeMKV and the 'save' option does not modify the files and ESPECIALLY does not encode .....
The mediainfo you post shows an Hdr10 encoding there is no dolby vision

[SeeMoreDigital]

I am using MakeMKV and the 'save' option does not modify the files and ESPECIALLY does not encode .....
The mediainfo you post shows an Hdr10 encoding there is no dolby visionThis is most likely an issue with MediaInfo.

The .m2ts file in the second report I posted was extracted directly from 'The Fifth Element' (StudioCanal) 4K UHD disc - Which looks beautiful by-the-way ;)

[ghostshadow]

This is most likely an issue with MediaInfo.

The .m2ts file in the second report I posted was extracted directly from 'The Fifth Element' (StudioCanal) 4K UHD disc - Which looks beautiful by-the-way ;)

Ok mais pourquoi alors il est encodé en x265 ?
Ok but why then is it encoded in x265?

[SeeMoreDigital]

Ok but why then is it encoded in x265?x265 = HEVC

[Stacey Spears]

And just to confuse matters further. There are two different enhancement layers.

MEL = 10-bit minimal enhancement layer (encoded at 2Mbps or below)
FEL = 12-bit full enhancement layer (encoded at 3Mbps or much, much higher)

In MEL, YCbCr are all set to 0 in the EL file. It is used to insert the RPU. Bad design, they could have just inserted the RPU into the base layer for MEL instead of this dummy file. 500 kb is the peak recommended for MEL.

In FEL, it stores the delta from the decoded base layer and the original 16-bit TIFFs. (12-bit is derived from the 16-bit TIFF) Dolby recommends 8 Mbps avg and 15 Mbps peak for FEL.

You can encode the base and EL with x265, I have. And then you use either Dolby Encoding Engine (DEE) or their SDK to do the rest. It is a multi step process.

The XML from Resolve is used in conjunction with the 16-bit TIFFs to generate an RPU binary file. The XML contains image statistics, trim pass and aspect ratio information. Additional metadata is pulled from the TIFFs.

[Stacey Spears]

Yes, x265 absolutely supports encoding Dolby Vision, but only the single-layer Profiles 5, 8.1, and 8.2. So not the dual layer profiles. Profile 5 encodes the same quality at about 20% lower bitrate than dual layer, so that's what everyone is using today for offline playback unless they NEED the SDR backwards compatibility for some reason.

Blu-ray uses Profile 7, which requires the dual layer system. Profile 5 does not offer 20% savings over profile 7 if you are using MEL. It is just one vs. two files.

Does profile 5 support 12-bit? I have mostly worked with profile 7, so not sure if it does or not. With the full enhancement layer, you do get 12-bit support.

[Blue_MiSfit]

FWIU Profile 5 can reconstruct 12 bit RGB using the 10 bit IPT base layer and the RPU. They do want you to feed in a 12+ bit (ideally 16) when shaping the image into 10 bit IPT.

Ben was also saying before that you actually can do Profile 5 now on UHD-BD (not just 7)

[Stacey Spears]

FWIU Profile 5 can reconstruct 12 bit RGB using the 10 bit IPT base layer and the RPU. They do want you to feed in a 12+ bit (ideally 16) when shaping the image into 10 bit IPT.

Ben was also saying before that you actually can do Profile 5 now on UHD-BD (not just 7)

Profile 5 cannot be used on BD, if Ben is suggestion it can, he would be mistaken.

The RPU does not contain any extra picture information, it just has the various Ls of information such as frame statistics and trim pass values. It is a pretty small file in binary form. Unfortunately BD does not support IPT either. I wish it did, my content shows noise in some super saturated red's due to non-constant luminance of YCbCr.

The output of the Dolby engine is always 12-bit, the LSBs are all 0 unless you encode 12-bit or you have a full enhancement layer to reconstruct the original 12-bit signal. IPT by itself does not offer any of that.

[ghostshadow]

ok that's it I managed to make an x265 encoded in dolby vision profile 8 from a UHD Dolby vision FEL Dual Track Dual Layer

[SeeMoreDigital]

ok that's it I managed to make an x265 encoded in dolby vision profile 8 from a UHD Dolby vision FEL Dual Track Dual LayerOut of interest... What's the movie?

[ghostshadow]

Midway Fr

[Blue_MiSfit]

The output of the Dolby engine is always 12-bit, the LSBs are all 0 unless you encode 12-bit or you have a full enhancement layer to reconstruct the original 12-bit signal. IPT by itself does not offer any of that.

Interesting. So what you're saying is that the output of profile 5 is effectively 10 bit, even though Dolby says the shaping of 12+ bit RGB input into 10 bit IPT lets them preserve more precision during playback?

[Stacey Spears]

Interesting. So what you're saying is that the output of profile 5 is effectively 10 bit, even though Dolby says the shaping of 12+ bit RGB input into 10 bit IPT lets them preserve more precision during playback?

Yes. IPTs benefit is constant luminance. With YCbCr at high nit saturated colors, you get visible noise in the image. This all goes away in IPT. Netflix and others have developed techniques to try and reduce the noise, but not nearly as effective as IPT. After encoding, they modify the analyze the Y channel and alter it for cleaner results and then re-encode.

Have you ever noticed the dark transition between colors on a color bars test pattern? That is due to non-constant luminance of YCbCr. IPT does not suffer from this either.

PQ, in general, is at least two bits more efficient than gamma. 12-bit PQ is like 15-bit gamma.

[Blue_MiSfit]

Gotcha. Thanks for sharing.

So, the question becomes - what matters more? 10 bit PQ IPT / ICtCp etc to reduce high saturation noise, or the effective 12 bit YCbCr PQ delivered by DV Profile 7 with a full res enhancement layer?

[Stacey Spears]

Gotcha. Thanks for sharing.

So, the question becomes - what matters more? 10 bit PQ IPT / ICtCp etc to reduce high saturation noise, or the effective 12 bit YCbCr PQ delivered by DV Profile 7 with a full res enhancement layer?

I don't know the answer. I included both FEL and MEL of the same clip and on today's consumer displays, hard to see much difference.

Streaming services are at a much lower bit rate than optical disc. That will make a difference.

I have the same rotating gradient pattern in both HDR10 and DV Profile 7 (MEL). On the C9, the DV has a smoother gradient. The DV is literally the HDR10 encode with dynamic metadata added, so the visual difference is the pipeline in the display. Dolby may simply have better dither, hard to say.

[Blue_MiSfit]

the visual difference is the pipeline in the display


I've absolutely found similar things. It seems Dolby does things "less wrong" inside the display than LG's default behavior with their HDR10 pipeline :)

[benwaggoner]

I've absolutely found similar things. It seems Dolby does things "less wrong" inside the display than LG's default behavior with their HDR10 pipeline :)
DoVi does their own certification, so DoVi implementations tend to vary less than stock HDR-10 implementations.

LG's HDR-10 implementation got a lot better in the last few years compared to their early HDR models.

[Blue_MiSfit]

Agreed. The B6 was terrible, and the C9 is quite good!

[chainring]

FYI: Anyone seeing the weirdness of MediaInfo reporting that a freshly backed up title having been encoded with x265 and what looks to be the normal command line parameters from a normal encode, update to MediaInfo 20.09. It's also properly detecting the DoVI in titles ripped with MakeMKV 1.15.2 and later.

[Boulder]

Can anyone enlighten me - what is the proper procedure to create DV (and HDR10?) supported Matroska streams? I'm still wondering if it's possible to re-encode the normal video track to a lower bitrate. Chances are that Kodi will support DV in the future so it would mean that I could use those directly in my media player library.

[SeeMoreDigital]

FYI: Anyone seeing the weirdness of MediaInfo reporting that a freshly backed up title having been encoded with x265 and what looks to be the normal command line parameters from a normal encode, update to MediaInfo 20.09. It's also properly detecting the DoVI in titles ripped with MakeMKV 1.15.2 and later.In my tests it would appear that MediaInfo v20.09 can reliably detect Dolby Vision meta-data for 'single-layer' encoded HEVC streams muxed within MP4, MKV, M2TS and TS containers.

But it's currently a bit 'hit-and-mis' detecting Dolby Vision meta-data for 'dual-layer' encoded HEVC streams.

I've backed-up quite a few 4K UHD discs but the Dolby Vision meta-data is not detected when 'dual-layer' streams are muxed within their original M2TS container.

[benwaggoner]

I've absolutely found similar things. It seems Dolby does things "less wrong" inside the display than LG's default behavior with their HDR10 pipeline :)
Yes, I'd say a core advantage of DoVi is that it's quality "floor" relative to the panel is higher than for HDR-10 implementations, due to Dolby's tuning and certification. Today's HDR-10 implementations from the major TV vendors are quite good, but there's a lot of variability outside of the top tier vendors and older models.

Plus dynamic metadata is a lot of help.

HDR10+ implementations, while not as proscribed as DoVi, are also very good from everything I've seen. The biggest challenge in tone mapping is how to adapt to potential variability, and static metadata isn't of much help. The best HDR-10 implementations do a lot of preanalysis of frames before display and statistical modeling. With dynamic metadata, there's no need to analyze and estimate, since the actual data is right there.

And while it's not possible to do much more than a frame or so of lookahead with dynamic metadata over HDMI (although even one frame is a lot of help), when doing playback of streams on a device, it's feasible to read the metadata many frames ahead for even smoother adaption, and more aggressive use of panel capabilities as less headroom is needed to reserve.

[jlpsvk]

ok... and now.. how can I get that RPU file for use with x265? maybe merge two BL.hevc with EL_RPU.hevc with yousesope's tool with "convert to 8.1"... this will create BL+RPU hevc stream, and then demux that hevc file and get BL.hevc and EL_RPU.hevc, but el_rpu.hevc should be only RPU file... which can be used for encoding with x265... did anyone tried that?

[SeeMoreDigital]

@jlpsvk,

You might want to checkout various discussions within this forums tsMuxer Open Source (https://forum.doom9.org/showthread.php?t=176668) topic.

[Balling]

Can anyone enlighten me - what is the proper procedure to create DV (and HDR10?) supported Matroska streams? I'm still wondering if it's possible to re-encode the normal video track to a lower bitrate. Chances are that Kodi will support DV in the future so it would mean that I could use those directly in my media player library.

You use official matroksa tools. But I really like mkv less and less. No DTS (decoding timestamps), only millisecond precision (but there is a patch to fix time scale), ffmpeg think all mkvs are VFR, insane. I am so tired of ffmpeg's more and more insane behaviour.