Dolby Vision Atmos update

Interesting - I can't think of any other reason to employ two decoders like that... and that is the spec of the base layer and enhancement layer - one is 4K and one is 2K...

 

The question remains whether the answer is soft on board who will use the technical ability to read DV files from FEL, but it should be noted that nowhere on the stands where this box is sold, there is nothing about Dolby Vision

 

This gt-king works very well and the majority of users use Coreelec on the homecinema-fr forum, but for DV nada

 

I assumed that there is no question of DV support anywhere, but then why the 4k + 1080p ?? what else can it be useful for ??

 

Hello ulna68,

if I don't make a mistake it's for the ISO DV support

to be confirmed by experts

 

Could just be PiP, video overlay etc.
Interestingly though I’m sure that Graphics chip is identical to the Mediatek/Arm chip used in the Oppo...
What sort of software support is there apart from corelec?

 

Just another Kodi box.

I know Dolby moved from their stance of never supporting media players but I think it'll be a cold day in hell before they allow dual layer processing without discs.

 

there may always be different overlays made by enthusiasts, no manufacturing company will break the license, and they will come with double-layer support

licenses and patents destroy this world, protecting large corporations

 

That's one way to look at it but I doubt a.n. other sat at home reading this forum is going to develop a movie grading standard then get filmmakers and hardware producers around the world to adopt this standard, be real somebody needs to get paid somewhere.

 

Hello all, very interesting discussion! A quick question, and please excuse me if this question has already been answered: in the case of FEL Blu-ray, is there any difference in the RPU layer/data as compared with, say, if that same Blu-ray were a MEL Blu-ray? In other words, can a FEL-sourced RPU data be used in its untouched form, to make a BL+RPU muxed file for playback (effectively simply discarding the EL)? In other words, is FEL RPU data intended to be applied specifically to the FEL stream or is it equally applicable whether or not FEL is being used?

 

Yes and no

Essentially the RPU data contained in a FEL title can be used in a MEL title but they can't be interchanged - In order to use a FEL RPU in a MEL title it must be converted (Dovi_Tools can be used to do this).

Don't forget that the RPU in a Profile 7 title has to be interleaved in an enhancement layer so in order to do as you say and just have BL+RPU you would need to convert the RPU to Profile 8 and interleave that in the base layer - again, Dovi_Tool can do this.

What you really don't want to do is to start stuffing the RPU from one grade into an HDR10 file from another grade - although technically it will work as long as the two are frame identical, an RPU should really only be applied from an HDR10 grade derived from the same Dolby Master (or Mezzanine).

 

Thank you very much for the response. What's interesting, based on my further experimentation, is that LG TVs (specifically the C1), for example, do play back and Dolby Vision gets triggered with files created by simply interleaving RPUs from a FEL or MEL Blu-ray into a Profile 8 output file. Now based on your answer, I'm not sure whether what gets played back in this case (without explicit conversions of RPUs to Profile 8) is actually "correct" in terms of the resulting picture or not.

 

What's the process you're using to get from Profile 7 BL+EL+RPU to Profile 8 BL+RPU?

 

In the case of MEL Blu-ray source, for example, I simply used dovi_tool without any Mode flags to drop the Enhancement Layer and keep the RPU; for example "dovi_tool convert --discard input.hevc". Given that nothing was set for the "--mode" flag, this command should simply keep the RPU untouched and discard the (M)EL. Haven't tried to achieve the same thing by using the "extract-rpu" command and then injecting it into the Base Layer, but I have a feeling it would work as well with the same end result. Finally, I mux the BL+RPU .hevc file into a .mp4 or a .ts container.

In the case of FEL Blu-ray source, using dovi_tool I extracted the RPU from the EL+RPU .hevc file (previously demuxed from the original .m2ts) and then simply injected that RPU.bin into the Base Layer. For the RPU extraction itself, I tried with both no --mode flag set (which should keep the RPU untouched) and using "--mode 1" (which "Converts the RPU to be MEL compatible"). Haven't tried using "--mode 2" yet. In all of these cases, after muxing the result to a .mp4 or .ts container, the resulting output plays on the LG C1 with Dolby Vision mode triggered.

But now I'm thinking about whether what actually gets played is correct or not.

 

I would assume that in that instance the TV is triggering Dolby Vision but the RPU isn't being referenced. The only way to test that I can think of would be to delay the RPU by say 24 frames and see if you can see the scene transitions.

But why not just set the mode flag to 2 and have a properly compliant Profile 8 file?

In the case of FEL above you should only use mode 1 if you're using Profile 7 and keeping a minimal enhancement layer which is a bit pointless when P8 does the same job without the extra layer - so again, use mode 2.

 

Generally, I would like to keep the source as untouched as possible, with the constraint of not being able to play FEL natively. I've been wondering whether it is legitimate to boil down the process to simply dropping the EL no matter the source and muxing BL+RPU without any further processing (similar to what Nvidia Shield does, but of course, not ignoring RPU).

Do these different "modes" that RPU can be in materially change the RPU data itself, or are these modes just different ways the RPU can be "muxed" in with BL video data? I.e., is there some "loss" by converting the RPU between the different modes when going from Profile 7 to Profile 8?

Edit: looking for a way to delay the RPU and do some more testing as you mentioned...

 

That's an interesting idea, although in converting to P8 you're losing the additional video info in the FEL for what it's worth...

My understanding is that changing the RPU from P7 to P8 has no detrimental effect or loss of metadata - might be an idea to pose a question on QuietVoid's Github page...

My suspicion is that using a P7 RPU might work on some players/displays and not on others - once you start messing out of specification you're open to all sorts of odd and unpredictable issues as we've seen with the Zidoo using certain homebrew DV solutions.

As I say, you should be able to test the RPU response by delaying the RPU a known amount then look for changes say 1s (assuming 24 frames delay) after the scene change - it will be subtle but obvious... Might have a go at that myself later...

 

OK, according to QuietVoid, only MEL Profile 7 RPU is lossless when converted to Profile 8. Which would imply by extension that Profile 7 FEL-sourced RPU cannot be used directly within Profile 8, that is, with just the Base Layer, unfortunately. If I'm reading it correctly. Yet the LG C1, for example, accepts such a combination. That is, simply running "dovi_tool extract-rpu fel_el.hevc", without any special Mode set, and then "dovi_tool inject-rpu ... bl.hevc" works on the LG.

Anyway, not sure if any of the known DV and muxing tools (TSmuxer, MKVtoolNix, dovi_tool) support introducing a delay during the muxing process. Now I'm dying to know whether the C1 actually uses Profile 7 RPU data within a BL+RPU file... My hunch is it does, otherwise it wouldn't activate the DV logo. Which it doesn't, for example, when presented with a full BL+EL+RPU file. (In that case it just says "HDR")

 

Yes, absolutely - P7 Mel > P8 is lossless because there's no FEL involved. P7 FEL to P8 loses the video residual of the FEL but the RPU maintains the same metadata.

I'm just extracting an RPU now as P7 and will inject back into a base layer with a delay to see what happens when the Zidoo plays it.

You have to introduce the delay into the RPU binary using JSON strings with Dovi_Tool Editor.

 

I think you're probably right, but we've had instances with the Zidoo during testing where Dolby Vision was being spat out but the RPU data wasn't being processed so that scenario is a possibility.