Check Dolby Atmos and Dolby Vision in current stream about rx-player HOT 3 CLOSED

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.

• The shaka-player defines a spatialAudio property on tracks when the EC3-specific SupplementaryProperty with "JOC" is found in the MPD (https://github.com/shaka-project/shaka-player/blob/ace3e37241dc04f26e35a9d69639b083551e356d/lib/dash/dash_parser.js#L1302-L1310).

  I like their solution as it's not too tied to this Dolby technology (you still have the "ec-3" codec to understand that you're probably dealing with what's called "Dolby Atmos" here on compatible devices - or DD+ on others).

• dash.js, videojs and other players I looked at didn't do anything.

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.

from rx-player.

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

from rx-player.

Now that the work has been merged:

• You can check if an audio track uses Dolby Atmos technology since the v3.32.1 by checking the isSpatialAudio property on an audio track (e.g. https://developers.canal-plus.com/rx-player/doc/api/Track_Selection/getAudioTrack.html)
• You can check for dolby vision on a video track since the v3.33.0 usually through the codec property (e.g. https://developers.canal-plus.com/rx-player/doc/api/Track_Selection/getVideoTrack.html), by checking usually for a codec string starting with "dvh" (see for example https://professional.dolby.com/siteassets/content-creation/dolby-vision-for-content-creators/dolbyvisioninmpegdashspecification_v2_0_public_20190107.pdf chapter 4.2.3)

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.

from rx-player.