HLS muxed audio missing format label

We have the following HLS (live) master playlist:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=130780,CODECS="mp4a.40.2",AUDIO="aac-primary"
../../<path>/chunklist_ao.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=130780,CODECS="mp4a.40.2",AUDIO="aac-backup"
../../<path>/chunklist_ao.m3u8
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac-primary",NAME="Home",LANGUAGE="eng",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2"
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac-backup",NAME="Home",LANGUAGE="eng",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2"
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac-primary",NAME="Away",LANGUAGE="eng",URI="../../<path>/chunklist_ao.m3u8",DEFAULT=NO,AUTOSELECT=YES,CHANNELS="2"
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac-backup",NAME="Away",LANGUAGE="eng",URI="../../<path>/chunklist_ao.m3u8",DEFAULT=NO,AUTOSELECT=YES,CHANNELS="2"

Based on the HlsPlaylistParser (line 514), if an audio track has no URI defined, then it will be stored in the muxedAudioFormat. However in this case, whenever we query the audio tracks, the muxed one has no id/label in the Format.

See the event logger’s output:

MediaCodecAudioRenderer [
  Group:0, adaptive_supported=YES_NOT_SEAMLESS [
    [ ] Track:0, id=0, mimeType=audio/mp4a-latm, bitrate=130909, codecs=mp4a.40.2, channels=2, sample_rate=48000, supported=YES
    [ ] Track:1, id=1, mimeType=audio/mp4a-latm, bitrate=130909, codecs=mp4a.40.2, channels=2, sample_rate=48000, supported=YES
  ]
  Group:1, adaptive_supported=YES_NOT_SEAMLESS [
    [X] Track:0, id=aac-primary:Away, mimeType=audio/mp4a-latm, codecs=mp4a.40.2, channels=2, sample_rate=48000, language=en, label=Away, supported=YES
    [ ] Track:1, id=aac-backup:Away, mimeType=audio/mp4a-latm, codecs=mp4a.40.2, channels=2, sample_rate=48000, language=en, label=Away, supported=YES
  ]

This is causing a problem for us, as we would need to select the tracks based on the labels. The question is whether the missing labels of muxed audio tracks is intentional or if it’s a bug? How could we workaround this issue on our side (without changing the manifest itself)?

Thanks in advance.

[guoen21]

I apply and test this commit locally, seems it also works for me, thanks very much!

Now we get two following muxed tracks, but the id is same, because we use one muxedAudioFormat, but from our master m3u8 it included two tracks which has no URI defined.

Group:0, adaptive_supported=YES_NOT_SEAMLESS [
  [X] Track:0, id=aac-backup:Home, mimeType=audio/mp4a-latm, bitrate=128206, codecs=mp4a.40.2, channels=2, sample_rate=48000, label=Home, supported=YES
  [X] Track:1, id=aac-backup:Home, mimeType=audio/mp4a-latm, bitrate=128206, codecs=mp4a.40.2, channels=2, sample_rate=48000, label=Home, supported=YES
]

expected

Group:0, adaptive_supported=YES_NOT_SEAMLESS [
  [X] Track:0, id=aac-primary:Home, mimeType=audio/mp4a-latm, bitrate=128206, codecs=mp4a.40.2, channels=2, sample_rate=48000, label=Home, supported=YES
  [X] Track:1, id=aac-backup:Home, mimeType=audio/mp4a-latm, bitrate=128206, codecs=mp4a.40.2, channels=2, sample_rate=48000, label=Home, supported=YES
]

[ojw28]

In here the language attribute of muxedAudioFormat may be miss, because of the playlistFormat.sampleMimeType is null.

This is a good observation. We’ll take a look; thanks!

In my commit I enhance it to support multiple muxed audio tracks

There is a TODO about this here. If you’ve implemented it, please feel free to send us a pull request. If you’ve implemented it in a different way then that might also be interesting, or you could try and adapt your approach to match what’s written in the TODO.