Support for CHARACTERISTICS in HLS subtitle track labeling callback

Requests
, ,
1

Currently not all data about an EXT-X-MEDIA is provided in the parameter of the SourceLabelingConfig callback. This severely limits the capabilities to provide robust language labels across all supported devices.

For example we often want to specify that a subtitle track contains closed captioning, and need to add [CC] to the label. However, because Bitmovin player (seemingly) only supports customizing this label based on the language code for HLS, we have had to devise a scheme of augmenting the language code, for example en-cc. However, this results in unintended behavior in iOS as the native iOS player attempts to convert the non-RFC5646 compliant language code into a label.

Ideally, we would have access to the CHARACTERISTICS values from the HLS manifest in order to apply appropriate labels to the subtitles and audio tracks.

This is specifically called out in the HLS authoring specification:

4.5. If a subtitles track is intended to provide accessibility for people who are deaf or hard of hearing, it MUST be marked with the attribute CHARACTERISTICS=“public.accessibility.transcribes-spoken-dialog,public.accessibility.describes-music-and-sound”. (Subtitles with this attribute value are treated the same as closed captions.)

The HLS specification provides the exact string which MUST be marked, this would be the ideal way to apply the appropriate labels in the Bitmovin player UI without buggy workarounds.

Ref: https://developer.apple.com/documentation/http_live_streaming/http_live_streaming_hls_authoring_specification_for_apple_devices

2

Hi Jon,

thanks for requesting this feature and sharing your requirement for it. We don’t currently have support for CHARACTERISTICS in HLS on our roadmap so I can’t share a timeline for this feature. However, I have captured your request so we can consider it in our future roadmap prioritisation.

Just to confirm, this would be mainly for the Bitmovin Player Web SDK?

3

Yes, currently we only utilize the Web SDK.

In the mean time is there a recommended workaround for this? Currently we’re generating two separate manifests for iOS vs everything else.

We’ll have one non-compliant manifest that uses en-cc to represent English [CC], and one that uses a HLS specification compliant manifest to indicate to the iOS player that the en subtitle track has closed captions. If we do not do this, iOS will improperly label the English subtitle track with an invalid region identifier (for example “English (Cocos Islands)”) .

This is obviously not a great fix, and being able to have a single compliant manifest would make both our internal system and compliance needs from our customers much smoother.

This may seem like a fairly trivial feature request, but it is a major blocker to our continued usage of the Bitmovin Player as our customers in the media & entertainment industry have very specific requirements when it comes to proper labeling of accessibility features.

4

Thanks, I do understand the problem you’re facing with this. Having an additional manifest sounds like a reasonable approach.

Alternatively, on Web (except Safari I’m afraid), you could use the preprocessHttpResponse to get access to the multivariant HLS playlist and store the relevant data to use in the labeling function afterwards. You could even manipulate the downloaded HLS playlist to match your needs in that callback, which is issued before the player even parses the downloaded file.