As I wrote in comment 4; the issue is with the check if we can re-use the init segment to prevent re-creating an audio decoder [1]. The logic introduced in bug 1450952 has limitation however. While it prevents re-creating a decoder; it also prevents re-creating a new demuxer. Bug 1530234 made the check wider so that we wouldn't re-create audio decoder with similar content (idea was that an existing decoder can easily decoder a similar stream). Unfortunately, the check fails if only the track id changed due to the YouTube workaround we placed in bug 1181981. There we force the track ID of audio to 1, and the video to 2. [2] [1] https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/dom/media/mediasource/TrackBuffersManager.cpp#1215-1219 [2] https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/dom/media/mediasource/TrackBuffersManager.cpp#1161 There two ways we could go at fixing this ; don't force the track ID on the AudioInfo until after we checked for the value of isRepeatInitData ; however this will make the bug we tried to fix in bug 1530234 come back with a 2s wait when changing audio track. The alternative would be to split the detection for a new decoder ; from the re-creation of the new demuxer. The first solution is the easiest to implement. The 2nd however, has significant advantages over the 1st. So I will go with the latter.
Bug 1679283 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As I wrote in comment 4; the issue is with the check if we can re-use the init segment to prevent re-creating an audio decoder [1]. The logic introduced in bug 1450952 has limitation however. While it prevents re-creating a decoder; it also prevents re-creating a new demuxer. Bug 1530234 made the check wider so that we wouldn't re-create audio decoder with similar content (idea was that an existing decoder can easily decoder a similar stream). Unfortunately, the check fails if only the track id changed due to the YouTube workaround we placed in bug 1181981. There we force the track ID of audio to 1, and the video to 2. [2] [1] https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/dom/media/mediasource/TrackBuffersManager.cpp#1215-1219 [2] https://searchfox.org/mozilla-central/rev/c14733e74e540b71856cc1d963bc424b38aa4bef/dom/media/mediasource/TrackBuffersManager.cpp#1161 There are two ways we could go at fixing this ; don't force the track ID on the AudioInfo until after we checked for the value of isRepeatInitData ; however this will make the bug we tried to fix in bug 1530234 come back with a 2s wait when changing audio track. The alternative would be to split the detection for a new decoder ; from the re-creation of the new demuxer. The first solution is the easiest to implement. The 2nd however, has significant advantages over the 1st. So I will go with the latter. Edit: actually doing 2nd is even easier