www.makemkv.com

Posted: **Sun May 01, 2022 1:36 pm**

quietvoid wrote: Sun May 01, 2022 1:18 pm
manuelrn wrote: Sun May 01, 2022 1:02 pmPerhaps 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.

Posted: **Sun May 01, 2022 1:38 pm**

manuelrn wrote: Sun May 01, 2022 1:36 pmAnd 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.

Posted: **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

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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.

Posted: **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

Posted: **Mon May 02, 2022 11:48 am**

NiCE77 wrote: 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.

Very interesting, so I played those files (including P5 fake/real) and I notice some periodic changes in the video stream of some of them (hue changes ?) but I couldn’t find explanation on how to interpret the usage of those test files. I did search here too, any clues/tips is greatly appreciated.

I feel really silly because I never got past the red screen in some of those files until now ... I thought the DV file was not being displayed correctly. Here's my noob observations for some of those test video files (P5/P8) using Infuse 7.3.10/ATV4K/LG E7:

1. RPU TEST SL fake p5.mp4 : dvhe.05.06, BL+RPU, BT.2020/PQ
- DV triggers, red screen, bunch of text on red/blue/red screen, scary guy staring at me
- I can't tell wether there's some scene by scene adjustment regarding to RPU
- According to recently found comment and that video display full screen, ATV 4K is not reading RPU from my created DV P5 using yusesope mode 2

2. RPU TEST SL real p5.mp4: dvhe.05.06, BL+RPU (missing meta data)
- DV triggers, some video aspects are periodically changing: brightness, hue, ... ?
- In some scenes I do notice the lights (specular highlights ?) are kinda bright.

3. RPU TEST SL p8.mp4: dvhe.08.06, BL+RPU, BT.2020/PQ
- same as (1) above

4. HLG DV P8 in sync.mp4: dvhe.08.07, BL+RPU, BT.2020/HLG
- can't tell much

Posted: **Mon May 02, 2022 11:59 am**

quietvoid wrote: Sun May 01, 2022 1:38 pm
manuelrn wrote: Sun May 01, 2022 1:36 pmAnd 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.

Okay, you're right.

Just to make sure, that bug is already fixed in version 1.5.1, correct?

Thank you!

Posted: **Mon May 02, 2022 1:10 pm**

Is there a command with ffmpeg to add black bars to a cropped 4k Dolby Vision video file? Can be mkv or m2ts or ts doesnt matter.

Posted: **Mon May 02, 2022 2:06 pm**

aboulfad wrote: Mon May 02, 2022 11:48 am Found this 2019 comment from @reset_9999
the FEL and RPU test files can also be used to find out if your device uses the L5 active area metadata in the RPU. if it uses L5, there will be black bars otherwise it will be fullscreen.

I'm not aware of any HDMI device that uses L5 metadata the way the TV's internal player does.
I really don't understand how L5 works on HDMI devices. Seems they all ignore it and are not affected by the issue described here: viewtopic.php?p=121490#p121490

Posted: **Mon May 02, 2022 2:37 pm**

manuelrn wrote: Mon May 02, 2022 11:59 amJust to make sure, that bug is already fixed in version 1.5.1, correct?

Thank you!

Yes, see release notes: https://github.com/quietvoid/dovi_tool/ ... /tag/1.5.1

mux: Fixed repeating EOS NALUs by default. Fixes #146.
This only affected the default muxing options. If using --eos-before-el, the output file was correct.

Posted: **Mon May 02, 2022 2:51 pm**

RESET_9999 wrote: Mon May 02, 2022 2:06 pm
aboulfad wrote: Mon May 02, 2022 11:48 am Found this 2019 comment from @reset_9999
the FEL and RPU test files can also be used to find out if your device uses the L5 active area metadata in the RPU. if it uses L5, there will be black bars otherwise it will be fullscreen.

I'm not aware of any HDMI device that uses L5 metadata the way the TV's internal player does.
I really don't understand how L5 works on HDMI devices. Seems they all ignore it and are not affected by the issue described here: viewtopic.php?p=121490#p121490

I am terribly sorry, I realized now I may have mis quoted your comment in my above response. My thread of questions were all related to P7 converted to DV P5 dvdhe.5.06 BL+RPU and may have confused L5 with P5 ? I still have to read/learn about RPU metadata to understand the link above. Ah DV metadata levels !!!
I am just searching in posts to learn about the video test files you made and how to interpret them on my device chain. Merci ; - )

www.makemkv.com

Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.