Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check Dolby Atmos and Dolby Vision in current stream #1266

Closed
klatoszewski-oke opened this issue Aug 2, 2023 · 3 comments
Closed

Check Dolby Atmos and Dolby Vision in current stream #1266

klatoszewski-oke opened this issue Aug 2, 2023 · 3 comments

Comments

@klatoszewski-oke
Copy link
Contributor

Hi there!

Is there way to check Dolby Atmos and Dolby Vision are playing in current stream?

Thanks!

@peaBerberian
Copy link
Collaborator

peaBerberian commented Aug 4, 2023

Hi!

For dolby atmos:

Looking at it a little, I see that from Dolby, all their provided MPD (so, for DASH) examples with dolby atmos are actually using what dolby calls JOC, for "Joint Object Coding", which is actually packaged in a Dolby Digital + format (with the ec-3 codec) and is retro-compatible to DD+ decoders.

To know that we're here handling Dolby Atmos JOC audio track in a player, they seem to advise the usage of two SupplementaryProperty elements in the MPD looking like this:

        <SupplementalProperty schemeIdUri="tag:dolby.com,2018:dash:EC3_ExtensionType:2018" value="JOC"/>
        <SupplementalProperty schemeIdUri="tag:dolby.com,2018:dash:EC3_ExtensionComplexityIndex:2018" value="16"/>

The first one indicating that this is JOC, the second one indicating the " decoding complexity of the enhanced AC-3 extension", "equal to the total number of bed objects, ISF objects and dynamic objects" (presumably pertinent for audio decoding only, in which case we may just ignore it?).

So now I'm wondering how the RxPlayer should behave when encountering this, while still allowing for future similar technologies and streaming protocol transparency.

I looked at what other players were doing.

I think indicating for spatial audio in audio track-related API could be a good way to signal Dolby atmos to an application for now, but this is not yet developed. You're welcome if you want to do it.

Dolby vision

We're used to (and we rely on this in production) it being simply defined as a specific codec, often beginning by the dvh string (e.g. dvh1.05.01).

However some examples on the web provided by Dolby seems to put it in a special "scte214:supplementaryCodecs" attribute instead. I don't know why and I hope this isn't frequent.

@peaBerberian
Copy link
Collaborator

Hi,

For dolby Atmos, this has been merged and release in the v3.32.1.

For dolby vision, we saw recently that some DASH packagers, like to announce Dolby vision in a supplementalCodec property (instead of just a codec one), following the SCTE 214 specification, to better indicate a retro-compatibility to non-dolby vision HDR10 content.

We're working on this here: #1307

@peaBerberian
Copy link
Collaborator

Now that the work has been merged:

I'm closing this issue now to facilitate our management of them, don't hesitate to re-open it if that's not clear or non functional for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants