Dolby Vision Atmos update

Hmm, I hope that's what QuietVoid meant to say. That is, that the metadata is the same. Because he said: "No, not all the modes round trip losslessly. Parameters in the RPU are changed, or even removed completely." He didn't specifically mention that this is what happens during the Profile 7 FEL -> Profile 8 RPU conversion, but given that he implied that that particular conversion isn't lossless, I'm afraid that might be the case. But I hope I'm wrong.

Great! Could you please share details of the required steps to introduce delay in the RPU binary? I'm not quite that experienced with dovi_tool but would like to try the same thing directly on the LG.

Edit: OK, I'm reading through the dovi_tool JSON editor documentation on GitHub right now; is it the "duplicate" JSON operation that achieves the delay somehow?

 

I think what he means is that parameters relating to the enhancement layer are lost, not the dynamic metadata.

Yes, that's it - so if you want a 24 frame delay for example, the JSON code is:

Code:

{
    "duplicate": [
        {
            "source": 0,
            "offset": 0,
            "length": 24
        }
    ]
}

 

Ok so I just reripped and re-encoded Indian Jones and the Last Crusade (encoded to 25Mbps).

This is a FEL title, so I then extracted the RPU as P7 (untouched) and injected it into the encoded HDR10 layer with a delay in the RPU of 24 frames.

MediaInfo sees the file as dvhe.07.06 BL+EL+RPU and MakeMKV has no idea what to make of it and sees it as dvhe.04.00 BL+RPU!!

As I'm sure you know there isn't a level 0 and Profile 4 is dual layer!!

Anyway, yes, the Zidoo plays the file fine and you can see the delayed RPU response, but I think I'd rather stick with the Profile 8 RPU... However, as belt and braces I'm just going to reinject a P8 RPU with a delay to make sure I get the same RPU response.

 

Thanks for the input! I can confirm the good news as well when a file with delayed RPU is played back directly on the C1; the RPU is pretty obviously being used in its original Profile 7 format -- during scene changes, there are clearly visible shifts in picture brightness happening with a one-second delay. I used the following sequence of commands to create the test file. I used a MEL Blu-ray backup, as that is what I have available right now:

Code:

 ./dovi_tool extract-rpu Dune.track_1.hevc -o dune_rpu.bin
 
 ./dovi_tool editor -i dune_rpu.bin -j rpu_delay.json -o rpu_delayed.bin
 
 ./dovi_tool inject-rpu --input Dune.track_1.hevc --rpu-in rpu_delayed.bin -o bl_with_delayed_rpu.hevc
 
 ./mp4muxer --dv-profile 8 --dv-bl-compatible-id 1 -o dune_final_delayed.mp4 -i bl_with_delayed_rpu.hevc

Next and final test: try the identical procedure on a FEL-sourced RPU, but I believe the result will be positive again, as this has nothing to do with MEL vs FEL, but rather with the source RPU Profile, and it just confirms that a Profile 7-type RPUs are being successfully utilized by the TV.

 

Just for my own curiosity, although I had tried this before, I used the same FEL file but remuxed the encode with a delayed P8 RPU and it behaved exactly the same as the P7 RPU.

 

That's great to hear! So both Zidoo and LG TVs can work with Profile 7 RPUs. This greatly simplifies the process of creating such files for our enjoyment Even though full FEL decoding would be even better of course

 

Interesting discussion in this thread's "revival", if you'd allow me.
Next to considering the mux of profile 7 or 8 RPU into baselayer, I wonder about

Can you confirm this with .mp4, (m2)ts and mkv? I have no LG experience, but I can imagine (any) tv's different handling capabilities regarding different containers. Also the difference between single- and dual-track might be in play here.

 

Well, I just tried muxing the same .hevc file to a .m2ts container using TSmuxer, as well as to MKV using MKVToolNix. And in both cases Dolby Vision didn't work on the C1. Dolby Vision mode didn't get triggered ("HDR" mode got triggered) and dynamic metadata wasn't being used.

Now I don't know whether that's due to the container format itself, or those particular muxing tools don't work in this case, or if I did something different than what's required to make it work.

Gonna try muxing to .mp4 again using Dolby's mp4muxer, this time with output profile set to 7 to see if that works in addition to using Profile 8...

Edit: Nope, using "--dv-profile 7" in Dolby's muxer doesn't work. Activates just the "HDR" mode. So we know that at least Profile 8 .mp4 works. Maybe Profile 4 would work as well. Also, according some comments on some other DV threads, LG TVs don't support Dolby Vision at all with MKV containers, so it's no surprise it didn't work in this case...

 

Definitely wouldn't expect MKV to work - I doubt the big names will ever touch that!

M2TS not working is also expected because even though it can work as such, it's not technically supposed to be a standalone container - it's supposed to be wrapped in a directory structure with playlists. So again not expected that the big boys would do that. Also wouldn't expect a TV to play the proper directory structure if presented with it, but it might.

I'm surprised MP4 didn't work since that's a standard industry transport mechanism for Dolby Vision but it may be restricted to Profile 5.

I think there are some Profile 4 demos to try over at 4Kmedia.org...

 

Yeah, but it's interesting, I think I vaguely remember some instances I tried previously where Dolby Vision did work when muxed to TS containers, but it might be me mixing something up...

Yeah, MP4 didn't work in that particular instance, but with Profile 8 flag set in Dolby's mp4muxer, it does work, as mentioned in previous posts.

Will now mux again using Profile 4 to see if that works also... But in the end, it doesn't matter, because we have a combination, Profile 8, where everything works (with RPUs left untouched coming from Blu-ray)

Edit: Yes, Profile 4 made with mp4muxer also works.

 

I think you should stick with Profile 8 as it's the only one that's properly Dolby compliant.

BL+RPU with a P7 RPU is out of spec and Profile 4 with an HDR base layer is out of spec too - it should be an SDR base layer (BT.1886 gamma and BT.709 colour).

But yeah, it's interesting as hell!

 

Yeah... not sure after all this discussion whether or not converting RPUs from Profile 7 to Profile 8 changes or removes some RPU data itself. I.e., is the process lossless in terms of the RPU data itself. That is the main question I would like to know the answer to, personally. Based on QuietVoid's (relatively high level) input, it isn't. So I kinda feel "safer" just keeping the RPU data untouched and true to the source, given that we've discovered that it works that way for our use cases...

 

Ok - you got me curious about this

So I compared some frames from both P7 and P8 RPUs derived from both MEL and FEL sources.

In all cases (to be fair, as I expected) with both MEL and FEL with both P7 and P8 RPUs, the only differences were the settings related to Profile 7. I confirmed this with reference to Dolby documents as well because there were a few things I didn't understand.

Both the MEL and FEL movies I tested contained Level 1, 2, 4, 5 and 6 metadata and all the global settings, tone mapping metadata and trims were exactly the same between the Profile 7 RPU and Profile 8.

This is an example comparison report for a FEL frame:

https://mega.nz/file/1b5ljYyB#FL7pXQEd3vNL2qphWB5NekRgzmoMMXSgTYX6nDQzBos

 

To be safe, have you considered keeping original RPU copies nevertheless? They are rather small and certainly for a limited number of DV videos, required harddisk space may be no problem. In which case, for future reference you may want to add a simple text file which would state the source and if there was syncing/cropping involved for usage on current files.

 

Unfortunately, I think I have some bad news related to my last conclusion; upon obtaining and testing the procedure I used above on some FEL Blu-ray sourced RPU data (which I promised to do), it seems that the resulting output (after simply dropping the EL) plays too dark on the C1. In comparison with a "Mode 2" output, this seems to be pretty visible. So it does seem that I jumped to the wrong conclusion after all, having used a MEL Blu-ray source initally. But this also shows that the dynamic metadata itself is also different in MEL vs FEL. I.e., the difference is not just the presence of an information-carrying Enhancement Layer, but the dynamic metadata itself is also different. My guess is that in the FEL case, the metadata expect, and therefore builds on top of, the full (possibly 4000-nit) layer, rather than the 1000-nit reference. Hence picture is rendered too dark.

Too bad... Now given my lack of understanding as to what exactly is that difference in the metadata itself between FEL and MEL (QuietVoid's answers to my questions were very brief and general and honestly not all that helpful), I have to wonder what exactly is it that one is watching when converting RPU from FEL to MEL or to Profile 8.1...? I have been trying to figure this out myself by analyzing the source code for dovi_tool, but I'm unfamiliar with Rust (or the inner workings of DV and RPU for that matter), so I can't really follow...

Edit 1:

Not sure how that is the case, given my observations above... Gonna try to compare the JSON (human-readable) forms of the RPUs for the FEL Blu-ray title that I have been using now when decoded directly vs. when converted to Profile 8.1 with dovi_tool...

Edit 2 / update:

OK, I extracted the RPUs for two selected frames in the video using the "dovi_tool info" command and I got the following results, which if I see correctly are very similar to what you got.

Code:

 diff rpu_untouched_frame4135.json rpu_mode2_frame4135.json > rpu_diff_frame4135.txt

https://ufile.io/fx7x1rc6

So something in those differences is causing the C1 to render the untouched RPUs wrongly (too dark)... But, I would assume those same differences would be present also in the case of MEL Profile 7 RPUs vs. Profile 8.1 RPUs, yet in that case the picture is identical on the C1 between Profile 7 and Profile 8.1 RPUs...

Very strange...

 

Yes - exactly the same results I got - that's all the EL data. That data isn't present in P7 MEL RPUs.

Presumably you're seeing this effect because the TV is expecting the enhancement layer and can't find it.

 

Hmm, I just tested a MEL sample (from this post from the MakeMKV forum), and I'm seeing the same differences. Meaning that same extra data that comes with Profile 7 is also present in the case of MEL Profile 7 RPUs... Also, what you said also plays into the possibility that in the case of FEL, the metadata somehow references things that exist in that Enhancement Layer, which, if not present, cause the player (in this case the TV) to misread things and play things the wrong way... Or, I guess in other words, the conclusion I'm drawing here is that Profile 7 MEL RPUs applied to the Base Layer gives the correct output, whereas Profile 7 FEL RPUs applied to Base Layer doesn't. Because the TV shouldn't be expecting to find the EL as it is incapable of playing it anyway...

What is this NLQ (non-linear quantizer) anyway? Maybe it is causing the difference?

What Dolby documentation were you referring to in your original follow up? Could you please link it?

 

Sorry - I was wrong in saying that MEL does not have an EL datablock - I was thinking of Profile 8 - Of course Profile 7 MEL and FEL both have this data since both have an enhancement layer, it's just in the case of MEL it's simply a mid grey field used as a placeholder (enhancement layer equal to zero as Dolby put it).

NLQ is just digitisation according to a mathematical formula as opposed to linear sampling.

So if I were you I'd go back to Plan A and use a P8 RPU.

(Sorry - I can't link to the Dolby docs because they're not public)

 

Hmm, I wonder what exactly do those fields where there are differences between Profile 7 and Profile 8.1 mean... If the only difference between Profile 7 and Profile 8.1 RPU is indeed entirely in those fields, then some of those fields are making the difference between correct and incorrect playback.

 

So, I just recently learned how to rip 4k MKV's using MakeMKV and I'm getting a layer 7 DV MKV file, which seems to play well and look very good. Is there something else I need to do or can do to make it better? I see you mention P8 several times. Do I need to convert it to P8 to get a better result, or is a better result possible?

Example would be Fate of the Furious. The MKV shows an HDR Format of "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU".