IOS Audio played does not match the one selected in player audio settings

Support
,
1

I have version Bitmovin on IOS 3.58.0.

Video *****.m3u8, Video has multiple audios (French, English, Korean…) and we set the default audio to Korean. When the source loaded the video did not play with Korean audio, but It played the video with French audio instead.

Even we use the setAudioTrack function

1 Like
2

Hi @hengsopharuth94,

How do you specify the default audio? Is it specified in the HLS manifest using the DEFAULT flag?

Even we use the setAudioTrack function

When in the lifecycle of the Player do you set this function? Ideally you call this after the Player is ready (aka. after an ReadyEvent was received)

3

Hi @davidsteinacher,

While I cannot confirm yet the use of setAudioTrack in the player lifecycle, I can confirm that the HLS manifest contains the DEFAULT flag on the Korean audio track. It seems to be ignored, French audio is selected by default when opening the player.

Reproduced on:

Screenshot 2024-04-05 at 10.20.46 in the morning
Screenshot 2024-04-05 at 10.20.46 in the morning2486×996 338 KB

Note: Due to confidentiality concerns, I cannot share the HLS manifest here. Let me know if I can get it to you in a secure manner.

4

HI @admin.vodfactory,

thank you for sharing additional details and the content of the multivariant playlist.

What I can see there is that both audio tracks have the AUTOSELECT set to YES. This allows the player to select any of them even if it is not set as DEFAULT when the Player thinks there is a better-matching audio track.

On Apple platforms (including iOS), this happens, e.g. when the device language matches one of the tracks (or better matches them). I tested it with one of our reference streams with the same characteristics and could observe the same behaviour. (This is expected behaviour)

I could see two ways forward:

  1. Setting AUTOSELECT to NO for all other audio tracks than the intended one
  2. The second option is to manually select the desired audio track once the player is ready. This could be done by listening to the ReadyEvent and calling setAudioTrack. This could look something like this:
player
    .events
    .on(ReadyEvent.self)
    .sink { _ in
        guard let audioTrack = player.availableAudio.first(where: { $0.language == "de" }) else {
            return
        }

        player.setAudio(trackIdentifier: audioTrack.identifier)
    }
    .store(in: &cancelables)

I quickly tried this approach and could observe an issue (most likely similar to the issue you described in your initial post). It seems that there is a problem with the initial audio track selection and what we communicate on our API (the audio track communicated is actually not the selected one). I’ve raised this issue internally.

In the meantime, a potential workaround could be to switch the audio temporarily to another track. This, combined with the code above, could look like this:

player
    .events
    .on(ReadyEvent.self)
    .sink { _ in
        guard let desiredAudioTrack = player.availableAudio.first(where: { $0.language == "de" }) else {
            return
        }

        // Workaround to temporarily select a different audio track
        if let currentAudioTrack = player.audio, currentAudioTrack == desiredAudioTrack {
            guard let tmpAudioTrack = player.availableAudio.first(where: { $0 != currentAudioTrack }) else {
                return
            }

            player.setAudio(trackIdentifier: tmpAudioTrack.identifier)
        }

        player.setAudio(trackIdentifier: desiredAudioTrack.identifier)
    }
    .store(in: &cancelables)

Note: Due to confidentiality concerns, I cannot share the HLS manifest here. Let me know if I can get it to you in a secure manner.

Yes, you can get in touch with our support in the Bitmovin Dashboard at Bitmovin Dashboard and create a new support case.

1 Like
5

Thanks @davidsteinacher for your feedback. We’ll most likely go with the workaround for now. Re-encoding our manifests to remove the AUTOSELECT attribute might be too heavy.

Could your team ping this topic when the problem would be fixed on an upcoming Bitmovin Player iOS SDK please?

1 Like