I have put up a PR that surfaces the Dolby Vision and HDR metadata of the playing stream as Kodi InfoLabels on CE22. The Dolby Vision RPU already passes through Kodi’s bitstream converter on the Amlogic path; this reads the metadata out of it and publishes it, so the process info can show what the stream actually carries: profile, level, enhancement layer type, the level 1 and level 5 values of the frame on screen, and the HDR10 mastering display and content light level data alongside it. It also carries fixes for two pre-existing bugs found on the way, one of which meant HDR10+ streams were reported as plain HDR10 on any TV that does not support HDR10+.
You’ve done a great job.
If this merged into CE 22, I’ll integrate as much of it as possible into TinyPPI. I probably won’t need all of it, but I’ll take whatever I need.
The difference is that it would be live instead of static, and we’d have the PQ values back.
Please modify it to touch as less of original XBMC code as possible. Like this big changes in bitstream converter. There is a upstream PR ongoing what will break everything again:
And upstream as much as possible to xbmc directly so it’s easier to maintain the code in future. We are not sure how to handle such big changes. It will be a nightmare on every rebase on xbmc/master. And we are 1-2 people…
TK are 10 or more? So best is to upstream as much as possible!
Like as example any changes in PPI XML/skin stopped us for rebase already a few times. Or you will be able to fix broken rebase on daily base?
I did check the PR yet in full as I am on mobile only right now.
We did and do discuss such item already a few times. It will become horror for us to keep the code base updated with xbmc/master as it’s a new “Kodi”.
We are more think about adding interfaces to provide such data to be able to use it with a add-on. So there will be minor code changes to the main core and rebase much more easy.
And the add-ons will not break every time on rebase.
Thanks, that makes sense. I hadn’t seen the annex-b refactor coming in xbmc#28791.
The better shape is probably what quietvoid also pointed at on the PR, which is to take the metadata from FFmpeg frame side data rather than the bitstream converter. Kodi master already reads that side data during decode for the DV profile and EL type (xbmc#27914), so the per-frame metadata and the InfoLabels can be built on top of that upstream, where they work on every platform FFmpeg decodes for and survive refactors like 28791. CoreELEC would then only need a small local producer for the Amlogic path, which never runs the FFmpeg decoder. The HDR10+ raw packet side data export already in the CE FFmpeg patches looks like a natural pattern for that.
That leaves a much smaller CE diff, with the churn living upstream. If the preference is to expose the data through an interface for add-ons rather than labels, the label layer can sit behind whatever interface lands. All my testing already runs through an add-on reading these values live.
This is becoming a significant problem for xbmc/master, as a lot of features aren’t — and won’t be — supported, simply because the platform itself isn’t supported.
We’ve noticed for a while now that Team Kodi’s focus has been on RPi and x86. It seems there is, and will continue to be, no DV support going forward.
The same applies to new features already supported by Amlogic and others, such as the VCC hardware decoder.
Attempts to contribute “improvements” upstream are often met with the response: “Who needs this?” Perhaps the answer is: the roughly 20k weekly CoreELEC users?
Unfortunately, it seems Team Kodi isn’t prioritizing Amlogic, which is currently one of the best media hardware platforms available.
I’ve personally stepped back from this as well and closed my upstream PRs, similar to what SamuriHL did. I’m sorry to say, but I suspect the same outcome may happen here.
Additionally, bringing on members from LibreELEC as GitHub managers for Team Kodi seems to be making things worse, as the focus on new features unsupported by RPi appears to be shrinking even further.
Sorry but I disagree, team-k with the help of @quietvoid made DV compatibility mode universal with all other hdr formats, is just fel that they don’t put much effort but of course which as you put it sometimes is a ‘niche’ market
They aren’t even able to implement a MEL/FEL detection as they do not support Amlogic platform. quietvoid changes origin come from CoreELEC platform and thanksfull some got upstreamed and accepted.
And why there are about 100 users daily request FEL support?
Mostly are Samsung users what don’t support DV at all .
I’ve closed that PR now as a result of thexai’s response and I’m still looking at what a more generalized solution could look like. But yeah, your diagnose looks to be spot on. I’m not going to give up entirely quite yet, but I’ve definitely lost a bit of faith that they will accept something this specific.
I hope there is still some way we could at least get some of this stuff in CoreELEC instead of forcing it to be handcrafted downstream in community builds. I’ll keep digging and see if I can come up with something. Appreciate all of the feedback!
Sorry to hear this. Yes, it seems to have become an impossible mission unless we manage to get some of the TK Devs’ attention. Either be a TK team member, or step back and let others weigh in.
If nothing works, we’ll take another look at how we can implement this with as little change to the original code as possible, in order to add the data filter and/or interface needed to access this data.
Actually, I have a working test build that covers the decoded half of what you describe. The Amlogic codec reads the RPU from the stream it is already handling, decodes it with libdovi, and publishes the values as Player.Process labels through a new CE label registry, so skins or add-ons like TinyPPI can use them as usual. HDR10+ per frame data could be added the same way later.
The registry keeps the labels in CE owned files, so new labels stop touching the shared Kodi tables and rebases get easier. The existing CE labels could move onto it too.
Raw data I have not built. Labels are the wrong channel for per frame raw data, so that would need a real add-on facing interface, and I wanted to try this simpler route first.
I can open it as a PR for discussion soon, I am just polishing it a bit first. It might help spark some new ideas, at the very least. I’m excited by this new approach because it removes all of the bitstream changes I made in my first attempt and keeps most things out of shared Kodi files
So, a new infolabel is added player.process(video.sidedata) which passes through the raw DV and HDR/HDR10+ metadata from the source packets as base64 encoded JSON. On it’s own, you can’t do much with this. So a new module has been added to the CE repo script.module.sidedata which parses the new infolabel and publishes all of the data as fields. Addons can use the module directly as a dependency, or skins can use the fields by using home window properties published by the module. All of the relevant details are included in the addon readme and fields documents.
@Portisch
Thank you very much for the offer to add TinyPPI to the CoreELEC repository. It’s definitely something worth considering.
At the moment, besides @matthane his new SideData implementation, TinyPPI also depends on script.module.audiodata. Audiodata reads the audio bit depth and sample rate from the source file and provides this information to TinyPPI.
If it were possible to expose the audio bit depth and sample rate as InfoLabels, the dependency on Audiodata would no longer be necessary.
After that, I could definitely imagine submitting TinyPPI to the CoreELEC repository.
It would certainly simplify things, since every user would then have direct access to TinyPPI from the CE Repository.
As we’ve already seen, when using passthrough it is reported as 8-bit, which makes the current InfoLabel unreliable. That’s exactly why I created this module in the first place. So the existing InfoLabel for audio bit depth can’t really be trusted for passthrough audio.
