Learning about Dolby Vision and CoreELEC development

I’ll do a bit more testing this weekend. I’ll DM you a couple of clips of stuff that isn’t doing what I would expect on the N2, but do play correctly on Ugoos and Homatics boxes into my LG C3.

I’ll also remove the Denon AVR from the path to see if that’s significant.

This is all TV-led stuff isn’t it (i.e. ICtCp 4:2:2 12-bit tunnelled as RGB 8-bit) - not Player-led aka LLDV?

It is all TV-led, but that doesn’t necessarily mean ICtCp. Whatever the actual format of the video is is what is used.

So for profile 8.1, p7 MEL and p7 FEL as MEL, it is YCbCr.

For profile 5 content it will almost be ICtCp. The almost because reshaping isn’t being done which makes output incorrect for p5 content (which should have reshaping)

Thanks for the clarification - so for TV-led YCbCr based 8.1 and 7 MEL/FEL as MEL stuff the YCbCr video is output tunnelled along with RPU (?) metadata on the top line of frame for the TV to use?

For Profile 5 stuff is the shaping a work in progress or a dead end?
(I see libplacebo talks about support for it?)

Pretty much, for what I’ve done the video signal is left untouched - it is played back however the stock version of CoreELEC would.

I have then added the metadata into the top rows of the OSD layer, which overlays the video. The metadata that is added is a part of the RPU data, but not all. The part added is the VdrDmData (dovi_tool/dolby_vision/src/rpu/vdr_dm_data.rs at 8ef53f252d56148c3cad9f8cc4ca76d40a9dfb20 · quietvoid/dovi_tool · GitHub) and the extension blocks.

The other part of the RPU, that is never intended to be sent to a TV, is information to do reshaping / composing of a FEL layer.

edit: the only reason this works for p8.1 compatible content is that it has no FEL layer to compose and the reshaping does nothing.


Haven’t really looked at it.

I don’t think libplacebo would work given CoreELEC does everything using hardware decode and a special lossless compressed format for the pixel data.

I think there is support in the kernel to use lookup tables though - think they may already be used to do HDR/SDR conversion? If they could be updated on a per frame basis the reshaping for profile 5 may be possible.

That said, it does appear possible on these amlogic chips. The related (banned from being named) *SMC seems to be doing the reshaping as a part of converting profile 5 content to HDR/SDR.

I can confirm that the un-named solution does play the 1080p Profile 5 DV stuff I have seemingly correctly in regular Rec 2020 PQ HDR YCbCr without the artefacts to do with overly bright levels I get on my N2.

I see this thread has now moved to the Unsupported / EOL HW/SW category. Pity, I was really hoping the CE team would incorporate this into their nightly / stable builds.

You have to see this functionality in grey area. CE supports “official” DV operation on devices which do support it.

thanks @vpeter, good to get an official response. May I be bold and ask a follow up question - is this to protect CE from legalities which could arise?

Perhaps I am too bold, so will assume silence to mean yes.

Well done @doppingkoala for pushing through even if your build won’t be incorporated officially. You’ve shown that DV capability is just software.

You don’t have to be bold to ask or to assume that if this is a grey area as Peter said, CE doesn’t need the problems that could arise. We’re just a half dozen guys enjoying a hobby.

And a large comunity that enjoys your hobby results :clap:

And that help greatly in moving forward! Thanks!

I remember that “a long time ago” CE team published user statistics for different boxes/SoC running different CE versions, number of users that chose to report this info.
I know that in professional/business environment such info is kept secret, but since you are not either, could you publish those numbers for everyone to see how has CE community evolved?

We are not professionals? :rofl:

If hobby is a profession, you certainly are :wink:

I have seen some discussions in different forums (not CE) about profiles used by standard DV and LLDV. For example some people are claiming that LLDV is tied/locked to profile 5 or profile 8 and cannot do profile 7? From what I have seen and tested DV or LLDV are not tied/locked to any profiles and DV and LLDV can use any profile? There are further claims that for LLDV to work with profile 7 the source device is converting it to profile 5 (or 8) to be used by LLDV which does not make sense to me? Does the CE code with the Ugoos AM6B+ has any of these limitations or profile conversion to be used for LLDV? Any official Dolby documentation/technical notes that explain DV/LLDV use of different profiles either way? Thank you.

P7 FEL works with LLDV with no issue

Thank you. I have used LLDV with P7 and FEL in my Ugoos so I know it works. This debate in other threads is a little strange since the arguments is that P7 FEL is being converted to P5 or P8 to be sent through LLDV, which as I mentioned on my previous post, I think it does not make any technical sense. So I am trying to find Dolby documentation / technical notes that establishes what profiles DV vs LLDV can use and if there are any limitations of profile conversions needed - which I assume is all profiles can be used for both DV and LLDV with no profile conversion needed.

Why would you need documentation? Just play the famous BL_EL.mkv file with LLDV activated and if you see the woman appear near the end of the video, you know FEL is working…

I am with you on this but the debate is that P7 FEL is being converted to P5 or P8 for LLDV. So the debators are implying that although you see the P7 FEL image that is has been converted to P5 or P8 for LLDV processing. Again this does not make sense to me.