The patch, allow audio master, commit 6f8a8f, fixes stall issues with ordering of updates of the DSN in segments across demuxed renditions however the cost is the seconds of delay on channel change or stream startup, a bad user experience.

To reproduce this bug start playback of any HLS live stream where audio timestamps precede video in the sequence of segments.

• Expected:

  1. Initial load of video sets start time reference
  2. Audio render is not started (samples are discarded, until they match video time)
  3. Playback starts immediately after first frame shows (early audio samples are discarded)

• Actual:

  1. Audio playback starts immediately
  2. First frame shows immediately (as this is a forced render, MediaCodecVideoRenderer forces first frame in processOutputBuffer()
  3. First frame is frozen until all audio preceding it plays out

This change to allow audio variants to reset timestamp adjustment fixes issues we have with live playback and marked discontinuities, so any fix must still address that issue. The bug here is simple.

1. Demuxed audio rendition playlist is updated, changing the discontinuity sequence (DSN)
2. Next audio segment blocks for timestamps (as a freshly minted TimestampAdjuster is picked up)
3. Video fetches continue on a stale DSN / TimestampAdjuster (cached version, or just the time ordering of the origin writing the playlists) so playback freezes

Because audio and video are kept in step by the CompositeSequenceableLoader (not allowing timeline progress) then playback is frozen forever.

Note the video rendition playlist will update to the new DSN, but the player does not see it.