Dolby Vision now possible through MP4 Mux.

Please post here for issues related to UHD discs
Message
Author
nekno
Posts: 56
Joined: Tue Jun 23, 2020 4:40 am

Re: Dolby Vision now possible through MP4 Mux.

#6436 Post by nekno » Sun May 01, 2022 8:39 am

aboulfad wrote:
Sat Apr 30, 2022 9:18 am
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.
Last edited by nekno on Sun May 01, 2022 9:13 am, edited 3 times in total.

nekno
Posts: 56
Joined: Tue Jun 23, 2020 4:40 am

Re: Dolby Vision now possible through MP4 Mux.

#6437 Post by nekno » Sun May 01, 2022 8:53 am

quietvoid wrote:
Sun May 01, 2022 12:04 am
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
Posts: 111
Joined: Sat Feb 09, 2019 12:51 pm

Re: Dolby Vision now possible through MP4 Mux.

#6438 Post by aboulfad » Sun May 01, 2022 11:03 am

nekno wrote:
Sun May 01, 2022 8:39 am
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.
[Oppo UDP-203, ATV 4K] —> Anthem MRX-720 —> LG OLED65E7P

quietvoid
Posts: 373
Joined: Sun Apr 19, 2020 4:15 pm

Re: Dolby Vision now possible through MP4 Mux.

#6439 Post by quietvoid » Sun May 01, 2022 12:13 pm

nekno wrote:
Sun May 01, 2022 8:53 am
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):
Image


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
Posts: 12
Joined: Fri May 22, 2020 10:39 pm

Re: Dolby Vision now possible through MP4 Mux.

#6440 Post by manuelrn » Sun May 01, 2022 1:02 pm

quietvoid wrote:
Sun May 01, 2022 12:13 pm
nekno wrote:
Sun May 01, 2022 8:53 am
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):
Image


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
Posts: 373
Joined: Sun Apr 19, 2020 4:15 pm

Re: Dolby Vision now possible through MP4 Mux.

#6441 Post by quietvoid » Sun May 01, 2022 1:18 pm

manuelrn wrote:
Sun May 01, 2022 1:02 pm
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.
manuelrn wrote:
Sun May 01, 2022 1:02 pm
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
Posts: 12
Joined: Fri May 22, 2020 10:39 pm

Re: Dolby Vision now possible through MP4 Mux.

#6442 Post by manuelrn » Sun May 01, 2022 1:36 pm

quietvoid wrote:
Sun May 01, 2022 1:18 pm
manuelrn wrote:
Sun May 01, 2022 1:02 pm
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
Posts: 373
Joined: Sun Apr 19, 2020 4:15 pm

Re: Dolby Vision now possible through MP4 Mux.

#6443 Post by quietvoid » Sun May 01, 2022 1:38 pm

manuelrn wrote:
Sun May 01, 2022 1:36 pm
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
Posts: 161
Joined: Sun Oct 11, 2020 12:05 am

Re: Dolby Vision now possible through MP4 Mux.

#6444 Post by staknhalo » Sun May 01, 2022 4:26 pm

quietvoid wrote:
Sun May 01, 2022 12:04 am
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 8)

nekno
Posts: 56
Joined: Tue Jun 23, 2020 4:40 am

Re: Dolby Vision now possible through MP4 Mux.

#6445 Post by nekno » Sun May 01, 2022 7:59 pm

aboulfad wrote:
Sun May 01, 2022 11:03 am
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 ?
In Infuse 7.3.9 and prior, DV5 with PQ EOTF or DV8.1 were fake DV, being displayed incorrectly with washed out colors because the ATV4K doesn't support those formats. It isn't clear whether the RPU was being applied, but it was being done incorrectly.
aboulfad wrote:
Sun May 01, 2022 11:03 am
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.
Correct, from Infuse 7.3.10 onward, any DV file with an HDR10 BL should display as HDR10 and not trigger DV on your display, because the ATV4K doesn't support any DV profile with an HDR10 BL.

Only DV5 with an IPT BL and DV8.4 with an HLG BL should trigger DV playback, because those are the only profiles supported by the ATV4K.

That is, until someone figures out what frankenstein methods Apple is using to trigger DV using P5 with an HDR10 BL and PQ EOTF in some of its screensavers.

Regardless, there is no legit workflow to go from DV7 DTDL to DV5 STSL because they aren't compatible. If you create a DV5 STSL file without re-encoding the entire HEVC video stream with IPT, you're creating a hybrid/frankenstein file that doesn't legitimately meet the DV5 spec in an attempt to trick some player hardware/software.

aboulfad
Posts: 111
Joined: Sat Feb 09, 2019 12:51 pm

Re: Dolby Vision now possible through MP4 Mux.

#6446 Post by aboulfad » Sun May 01, 2022 8:54 pm

nekno wrote:
Sun May 01, 2022 7:59 pm
... Correct, from Infuse 7.3.10 onward, any DV file with an HDR10 BL should display as HDR10 and not trigger DV on your display, because the ATV4K doesn't support any DV profile with an HDR10 BL.

Only DV5 with an IPT BL and DV8.4 with an HLG BL should trigger DV playback, because those are the only profiles supported by the ATV4K.
...
jfyi the linked STSL DoVi P5 mp4 in my previous post does trigger DV on my LG using Infuse 7.3.10/ATV 4K. The colours appear ok to my eyes, but for sure they aren't washed out for that small clip. I assume that STSL is an DV/HDR10 BL as the color primaries are rec.2020 and transfer function is PQ ? so hence the "frankstein" designation. If you think it's an Infuse 7.3.10 bug, I'll report it on their community.
[Oppo UDP-203, ATV 4K] —> Anthem MRX-720 —> LG OLED65E7P

deadchip12
Posts: 285
Joined: Thu May 02, 2019 2:49 am

Re: Dolby Vision now possible through MP4 Mux.

#6447 Post by deadchip12 » Mon May 02, 2022 5:00 am

Is anyone here using windows 11? Is it possible to play dolby vision m2ts files on pc yet? I see there is a new media player app on win 11 but at the moment I don't have the hardware to test dolby vision myself.

nekno
Posts: 56
Joined: Tue Jun 23, 2020 4:40 am

Re: Dolby Vision now possible through MP4 Mux.

#6448 Post by nekno » Mon May 02, 2022 7:49 am

aboulfad wrote:
Sun May 01, 2022 8:54 pm
jfyi the linked STSL DoVi P5 mp4 in my previous post does trigger DV on my LG using Infuse 7.3.10/ATV 4K. The colours appear ok to my eyes, but for sure they aren't washed out for that small clip. I assume that STSL is an DV/HDR10 BL as the color primaries are rec.2020 and transfer function is PQ ? so hence the "frankstein" designation. If you think it's an Infuse 7.3.10 bug, I'll report it on their community.
Interesting, perhaps I misinterpreted their update to mean they were looking at the BL when they're really just being more strict in looking for DV5 or DV8.4, disallowing DV7 and DV8.1 and falling back to HDR10 when not DV5 or DV8.4.

Since you converted the DV7 RPU to DV8.1 with dovi_tool mode 2, but then presumably set the profile to DV5 with mp4muxer, that seems to be enough to get by Infuse's new checks and trigger DV.

I'll do some testing and see if I can tell if it's successfully tricking the ATV4K into applying the RPU for DV or if it's fake DV.

I'm behind the times on mp4box/gpac capabilities in remuxing DV files, as well as the ability of x265 to encode DV5, so I'll have to look into it more.

NiCE77
Posts: 86
Joined: Sat Mar 28, 2020 7:49 am

Re: Dolby Vision now possible through MP4 Mux.

#6449 Post by NiCE77 » Mon May 02, 2022 10:11 am

nekno wrote:
Sun May 01, 2022 7:59 pm
Only DV5 with an IPT BL and DV8.4 with an HLG BL should trigger DV playback, because those are the only profiles supported by the ATV4K.
It seems, that ATV 2021 does not use the RPU for HLG based P8.4 videos either. I checked with RESET_9999 videos.

aboulfad
Posts: 111
Joined: Sat Feb 09, 2019 12:51 pm

Re: Dolby Vision now possible through MP4 Mux.

#6450 Post by aboulfad » Mon May 02, 2022 11:43 am

nekno wrote:
Mon May 02, 2022 7:49 am
… Since you converted the DV7 RPU to DV8.1 with dovi_tool mode 2, but then presumably set the profile to DV5 with mp4muxer, that seems to be enough to get by Infuse's new checks and trigger DV. …
Sorry I mentioned earlier I used yusesope mode 2 to create a STSL but you are correct on the latter part.

Btw I found some of my commands that created that linked mp4 but sadly never backed up that directory with all my files. I can redo what I toyed with 1.5 years ago but I think the consensus is clear on “proper” conversion/rip from UHD P7 DV to P5 for Infuse/ATV 4K DV consumption.

Code: Select all

bl_el_rpu_builder-0.0.3.py -bl pBL.hevc -el pEL.hevc -of pBL_RPU.hevc -mode 2
mp4muxer -i pBL_RPU.hevc --dv-profile 5 -o pBL_RPU_p5.mp4
mp4box -add pBL_RPU_p5.mp4+truehd.mp4 -brand mp42isom -ab dby1 -no-iod pBL_RPU_p5_truehd.mp4
Last edited by aboulfad on Mon May 02, 2022 11:03 pm, edited 1 time in total.
[Oppo UDP-203, ATV 4K] —> Anthem MRX-720 —> LG OLED65E7P

Post Reply