Dolby Vision now possible through MP4 Mux.

[drew_nickel]

great explanation @nekno
I'll pin your comment in the excel sheet. thanks

Yes! great explanation @nekno! Thank you guys for helping me understand it. Thank you too @reset for all your help! Your scripts are excellent! I use your method and I also use @yusesope's and I've been making alot excellent and flawless conversions

The size of the FEL layer is what baffled me the most. Didnt realize that it was its own video stream of the 1080p. Makes alot of sense now. I've been looking for that answer for a while now

And that Total Recall screenshot comparison is really helpful and interesting too

[ArArdin]

Just to expand on this a little...

Kudos indeed for your clear explanation, nekno.

Could you explain why the enhancement layer is always shown as 1080p and not in 4K resolution?
I can imagine it's just extra sub-sampling into a smaller footprint for compression efficacy. Where I wonder if this would be possible because the data itself is differential, and/or the source being encoded in 4:2:0 color subsampling.

Any thoughts?

[aboulfad]

…
The RPU contains trim data — adjustments for different brightness displays — often for 100nits (SDR) and 600nits. When your device's EDID indicates an 800nit max, the 100nit and 600nit trims are used to produce a picture that's as close as possible to the 10000nit or 4000nit or 1000nit master.

That will be true with either an MEL or FEL.
…

Thank you for an interesting read, complimentary to the very useful post viewtopic.php?p=85181#p85181 about DoVi tracks/layers by yusesope.
IYO, what is the impact on screen by screen (or frame) display brightness when a workflow is followed to convert DV P7 DTDL BL+MEL+RPU to P5 STSL BL+RPU where the EL (MEL) is discarded? (Putting aside the color space differences)

[nekno]

Could you explain why the enhancement layer is always shown as 1080p and not in 4K resolution?
I can imagine it's just extra sub-sampling into a smaller footprint for compression efficacy. Where I wonder if this would be possible because the data itself is differential, and/or the source being encoded in 4:2:0 color subsampling.

Any thoughts?

The short answer: Because that's what the DV spec specifies for P7. It was just a choice to make it work within the UHD BD spec, for efficiency and bandwidth. You only need to encode 2 bits of color data in the EL; you don't need a full 2160p 10-bit stream for that. Moreover, decoding two simultaneous 2160p60 HEVC streams @ 130Mbps requires twice the throughput of the overall system as compared to a single stream. Lowering the max EL down to 1080p60 @ 70Mbps lessens those hardware/software constraints considerably (from 2x to ~1.5x for the coded picture, and from 2x to 1.25x for the decoded picture).

The long answer, breaking down Dolby Vision Profiles and Levels:

As we know, DV has profiles, which specify:

• video codec, video profile, and video level
• single or dual layer (BL+RPU or BL+EL+RPU)
• cross-compatibility IDs (CCIDs) that specify the BL characteristics (SDR, HDR10, HLG)

DV Profile 7 specifies:

• 10-bit HEVC video (HDR10) for both BL and EL
• a 1:1 ratio in BL:EL if the BL is FHD (1080p), which equates to a max of DV Level of 5
• a 1:1/4 ratio in BL:EL if the BL is UHD (2160p), with a max DV Level of 9

So DV also has levels.

The Profile specifies constraints on the Level based on the specs of the BL.

So if you want a BL of 3840*2160*24fps = 199,065,600 pixels per second (pps), that equates to DV Level 6:



So with DV Level 6, you're beyond the limit of DV Level 5 for a 1:1 BL:EL ratio, and therefore the EL has to drop to 1/4 the pps of the BL, per the spec. The pps of DV Level 5 is 1/4 the pps of DV Level 9, hence a BL of Level 9 will be limited to an EL of Level 5.

With a BL of DV Level 6, which is where you see UHD BD P7 encodes, 1/4 the pps limits you to an EL of Level 3. And basically you only see UHD BD movies with BLs of at least Level 6, because that's what you need for 2160p24, and only ELs of Level 3, because that's what you need to support 1080p24.

When you see "dvhe.07.06", that's a "DV codec string" that's specifying:

• DV Profile string: "dvhe.07" — Dolby Vision, HEVC video codec, Profile 7
• DV Level ID: "06" — the max pps specified by Level 6

Lastly, you have the CCID (which isn't included in the DV codec string):

• when you see "DV 8.1", "DV P8.1", or "DV Profile 8.1", that's specifying:
  • Profile: 8 — all the constraints of DV8
  • CCID: 1 — which specifies the BL must be HDR10
• when you see DV 8.4, that's specifying:
  • Profile: 8
  • CCID: 4 — which specifies the BL must be HLG

[quietvoid]

If anyone's interested, I just added muxing BL+EL to dovi_tool.
There's no release yet but testing would be nice, more info here: https://github.com/quietvoid/dovi_tool/ ... 1114074639

This now makes dovi_tool feature complete in comparison to yusesope's script. It's also faster.

edit: It is now available in version 1.5.0: https://github.com/quietvoid/dovi_tool/ ... /tag/1.5.0

[RESET_9999]

thanks... seems to work well and faster indeed.

[nekno]

IYO, what is the impact on screen by screen (or frame) display brightness when a workflow is followed to convert DV P7 DTDL BL+MEL+RPU to P5 STSL BL+RPU where the EL (MEL) is discarded? (Putting aside the color space differences)

I mean, there isn't really a workflow that goes from DV7 -> DV5, is there? Because of the diff in color space, you'd have to re-encode the HEVC video stream. And if you have access to an encoder that supports IPT, don't you just have access to the DV software suite, such that you'd be able to completely reproduce RPUs and trims that match the frames of the new encode exactly, instead of having to transfer the RPUs from the DV7 encode?

Regardless, to my eye, IPT does produce great quality encodes with better efficiency. So if you take a high bitrate HEVC video stream from a UHD BD and re-encode it with an HEVC encoder that supports IPT, then apply the RPU from the P7 encode, you should be able to produce a pretty good result. It isn't that different than how one might re-encode a UHD BD or BD to a lower bitrate for streaming with x264 or x265, and with IPT you'll be getting better picture quality at a given bitrate.

If you go from DV7 MEL -> DV8.1 without re-encoding the underlying HEVC video stream, then you're losing literally nothing, so that would obviously be better quality than re-encoding to DV5. DV7 BL+MEL+RPU is going to be an equivalent presentation to DV 8.1 BL+RPU.

There's also an argument to be made that the extra 2 bits of color in an FEL represent brightness levels in specular highlights that current consumer display panels can't achieve; they represent values of 1000-4000nits. So if our displays can't display them, what's the point in having the FEL at all? Because it isn't that simple. The problem gets murky in scenarios like the Total Recall example that RESET_9999 shared, where the overall picture quality and fine detail improves with the video data from the FEL recombined into the decoded picture.

So, it seems to me, if a UHD BD has an FEL available and you want to know you're seeing the best possible picture quality (inclusive of the placebo effect), then you'd better watch it as a DV7 FEL encode. If the UHD BD only provides an MEL (or is only available as an HDR10 or HDR10+ release, so you're recreating your own hybrid BL+RPU), then DV8.1 is equivalent to what you're going to get watching DV7 MEL.

[nekno]

If anyone's interested, I just added muxing BL+EL to dovi_tool.
There's no release yet but testing would be nice, more info here: https://github.com/quietvoid/dovi_tool/ ... 1114074639

This now makes dovi_tool feature complete in comparison to yusesope's script. It's also faster.

edit: It is now available in version 1.5.0: https://github.com/quietvoid/dovi_tool/ ... /tag/1.5.0

This is fantastic to have with the speed of dovi_tool. Thank you!

It looks like you were discussing making `--eos-before-el` default to `true` to match yusesope's tool but opted not to do that in the end.

Can you share why or in what scenarios we would want `--eos-before-el` enabled or disabled?

[aboulfad]

I mean, there isn't really a workflow that goes from DV7 -> DV5, is there? Because of the diff in color space, you'd have to re-encode the HEVC video stream. And if you have access to an encoder that supports IPT, don't you just have access to the DV software suite, such that you'd be able to completely reproduce RPUs and trims that match the frames of the new encode exactly, instead of having to transfer the RPUs from the DV7 encode?
...

Thank you for another informative post - I must have foolishly created (more than a year ago) under the false impression a frankstein DoVi mp4 DTDL P7 (UHD BD) to STSL DV P5 using mode 2 of yusesope tools. TBH don't know what I ended up with, as mediainfo confirms its a STSL (BL+RPU) with a transfer function PQ which I guess is that of the UHD disc (Black Panther) ?

As the BL transfer function from the extracted disc is PQ and different than what a P5 DV streaming device expects IPT/ICtCp (mp4-> Infuse/4K ATV), one would expect the colours to be somewhat off (hard to tell with the above short mp4). Using that frankstein workflow, is the RPU applying its metadata screen by screen (or frame by frame) regarding "brightness" ? is there an objective method to find out short of subjectively trying to eye ball it ?

From what I read here and in firecore community, there isn't an open source workflow that would yield a proper DV P7 DTDL -> DV P5 STSL for the ATV 4K.

[quietvoid]

It looks like you were discussing making `--eos-before-el` default to `true` to match yusesope's tool but opted not to do that in the end.

Can you share why or in what scenarios we would want `--eos-before-el` enabled or disabled?

It's simple, if you want the output to be identical to yusesope, then use --eos-before-el.
MakeMKV behaves the same as yusesope, but output NALU start codes are not always size 4.
The flag only affects the ordering of the EL NALUs for the last frame, and only if there's an EOS or EOB NALU.

I went with how the HEVC spec orders them (list ordering):



So UNSPEC63 (EL) comes before EOS.
This behaviour makes more sense to me than having the BL EOS before the final EL NALUs.
I don't know if it makes a difference.

[manuelrn]

It looks like you were discussing making `--eos-before-el` default to `true` to match yusesope's tool but opted not to do that in the end.

Can you share why or in what scenarios we would want `--eos-before-el` enabled or disabled?

It's simple, if you want the output to be identical to yusesope, then use --eos-before-el.
MakeMKV behaves the same as yusesope, but output NALU start codes are not always size 4.
The flag only affects the ordering of the EL NALUs for the last frame, and only if there's an EOS or EOB NALU.

I went with how the HEVC spec orders them (list ordering):



So UNSPEC63 (EL) comes before EOS.
This behaviour makes more sense to me than having the BL EOS before the final EL NALUs.
I don't know if it makes a difference.

Anyway, if I have not misunderstood you, the difference between using the --eos-before-el flag or not using it only changes the last frame of the video, that is, it only changes the end of the file, correct?

So if only the end of the file is changed then it should not affect the playback of the video, because when the player reaches that point it will be time to close the playback.

Perhaps it could be something important in videos coming from a seamless branching disc, as sometimes the end of each m2ts contains EOS/EOB NALUs. I think this happened for example in Fast & Furious 9, which caused problems in MKVToolNix and had to be updated.

[quietvoid]

Anyway, if I have not misunderstood you, the difference between using the --eos-before-el flag or not using it only changes the last frame of the video, that is, it only changes the end of the file, correct?

Yes.

Perhaps it could be something important in videos coming from a seamless branching disc, as sometimes the end of each m2ts contains EOS/EOB NALUs. I think this happened for example in Fast & Furious 9, which caused problems in MKVToolNix and had to be updated.

It would need to be tested. Maybe the MKVToolNix issue was caused by MakeMKV.

edit: It's actually the cause: https://gitlab.com/mbunkus/mkvtoolnix/- ... _669504990
So using `--eos-before-el` is wrong.

There might be a bug with F9 though, I'll have to verify.

[manuelrn]

Perhaps it could be something important in videos coming from a seamless branching disc, as sometimes the end of each m2ts contains EOS/EOB NALUs. I think this happened for example in Fast & Furious 9, which caused problems in MKVToolNix and had to be updated.

It would need to be tested. Maybe the MKVToolNix issue was caused by MakeMKV.

edit: It's actually the cause: https://gitlab.com/mbunkus/mkvtoolnix/- ... _669504990
So using `--eos-before-el` is wrong.

There might be a bug with F9 though, I'll have to verify.

And in those cases, would it be possible for dovi_tool to omit those EOS/EOB NALUs and keep only the last one? (when muxing and injecting)
That is, if dovi_tool finds any EOS/EOB NALUs it checks if it is the last frame of the video, and if it is the last frame then dovi_tool keeps EOS/EOB NALUs but if it is not the last frame then it does not write that EOS/EOB NALUs.

Perhaps this is more appropriate, since that information makes sense in individual m2ts files but it does not make sense for that data to still be present once all those videos have been demuxed and merged into a single video file.
This also saves us from any kind of problem.

[quietvoid]

And in those cases, would it be possible for dovi_tool to omit those EOS/EOB NALUs and keep only the last one? (when muxing and injecting)
That is, if dovi_tool finds any EOS/EOB NALUs it checks if it is the last frame of the video, and if it is the last frame then dovi_tool keeps EOS/EOB NALUs but if it is not the last frame then it does not write that EOS/EOB NALUs.

No, it wouldn't be able to know how many frames there are.
I'd also rather not discard anything unnecessarily.

There's indeed a bug in 1.5.0 for files with multiple EOS NALUs present.
I'll add some tests and push the fix later.

[staknhalo]

If anyone's interested, I just added muxing BL+EL to dovi_tool.
There's no release yet but testing would be nice, more info here: https://github.com/quietvoid/dovi_tool/ ... 1114074639

This now makes dovi_tool feature complete in comparison to yusesope's script. It's also faster.

edit: It is now available in version 1.5.0: https://github.com/quietvoid/dovi_tool/ ... /tag/1.5.0

nice, thank you