Special audio tracks in AVPlayerViewController audio selector

We are facing an issue with the audio tracks displayed by AVPlayerViewController in our tvOS client.

When we have a stream with alternative audio tracks, we set for sure the language and the name in the manifest of the HLS stream as described by https://tools.ietf.org/html/rfc8216

eg:

Code Block
NAME="French",DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="fr"


This works for common audio tracks with different languages. The Audio Track is then displayed correctly by AVPlayerViewController, showing the name of the language localized based on the user's device language preference.

But as soon as we offer more special audio tracks like "Miscellaneous" our audio track is defined like:

Code Block
NAME="Other (mis)",DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="mis"


When it comes to displaying these audio tracks to the customer, they appear as "mis". This cryptic Audio Track name is the issue.

Other "special" audio tracks with the same issue are:
  • mis, for "uncoded languages"; for languages that have no code yet assigned

  • mul, for "multiple languages"; should be applied when many languages are used and it is not practical to specify all the appropriate language codes

  • nar, for “narrated audio stream”; audio descriptions to hear narration describing a video clip

  • qaa-qtz, a range reserved for local use → original language, not specified = OV

  • und, for "undetermined"; is provided for those situations in which a language or languages must be indicated but the language cannot be identified

  • zxx, for "no linguistic content; not applicable"; may be applied in a situation in which a language identifier is required by system definition, but the item being described does not actually contain linguistic content

Is there a way to display custom display names for the audio tracks in the AVPlayerViewController audio selector?

Use case


Our use case is an App which plays live tv streams.

The signal comes from the broadcasters and we have no influence on it. Therefore we can not avoid using any special language code that they decide to use to describe their audio content.

At the same time though, we want to make it as user friendly as possible, and to display a human readable name to our users for all language code in a consistent way. That includes those unknown language codes, but it also includes displaying known language codes with a consistent naming through the whole platform.

Observed behaviour


The UI for the Audio track selector in AVPlayerViewController takes into account the LANGUAGE attribute from HLS.

We observed that when the language uses a language code (e.g. en-US) it is translated to the appropriate localized string to show the user based on their device language preference.

On the contrary, when including non language code values, including special audio track codes also part of ISO-639-3 as "mis", "mul", etc... we observed that they are not localized and they are directly displayed as a string.

That means that given the following language in the manifest, the audio selector will show the name "Hello World"

Code Block
NAME="French",DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="Hello World"




Replies

Please file an enhancement request using the Feedback Assistant asking for playlist-defined localizable names as described by your specific use case.

Note you have more control with MEDIA tags with AUTOSELECT=NO. In that case, the value of the NAME attribute is used. Otherwise, the displayed name is based on the values of other attributes including some or all of them that are used to determine tracks’ eligibility for automatic media selection. The values of TYPE, LANGUAGE, and CHARACTERISTICS certainly determine portions of the displayed name.
Part of the earlier reply is a bit misleading.
On Apple devices, AUTOSELECT="YES" is only useful if the LANGUAGE code matches the locale. For anything odd that is never going to be the case, so specifying YES does nothing. On the other hand AUTOSELECT="NO" will use the value of the NAME attribute as the display name when the user’s most preferred language matches the language of the variant. So using NO won't get you what you want either.

For the specific case of 'nar' (for “narrated audio stream”), you should never use it, because it makes it impossible to identify the spoken language used in the audio description. Instead the CHARACTERISTICS attribute should include "public.accessibility.describes-video", as mentioned in the HLS Spec and in the Authoring Spec.

One last point. The LANGUAGE attribute is defined as a string corresponding to RFC5646. Since, LANGUAGE="Hello World", does not match that spec, any client could legitimately decide to simply ignore the value entirely.