1679283 - [MSE] issues appending data when audio with a different track_id is encountered

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[pea.berberian]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Setup

I played multiple DASH contents with two MSE media players (the issue does concern the browser and not those players, bear with me):

1. The RxPlayer (MSE/EME player from Canal+), which I work on
2. The Shaka-Player (MSE/EME player from Google) which might be a little more known (for now !)

The corresponding contents have a particularity:
They have different audio tracks, each linked to an initialization and media segments which contain, as expected, only the data for the corresponding track, but each with a different track_id set in the corresponding ISOBMFF boxes.

For example, in a test content, I have two tracks:

1. a french track, which has segments containing a track_id set to 2
2. an english track, has segments containing a track_id set to 3

With MSE contents, we usually encounter a common track_id in all segments, as every segments only contain data for one track at a time. But I don't see anything wrong with different track_id as long as an initialization segment is provided to the SourceBuffer in the meantime.
So this may be unusual but those contents should decode on Firefox just fine.

Steps

When playing that content, then switching the audio track, both of those players continue to use the same audio SourceBuffer as long as the audio codec did not change.

So, let's say, when we switch from an audio track with segments having a track_id set to 2 to one set to 3:

1. we push an initialization segment for that new audio track on the same SourceBuffer
2. we push media segments of that new tracks on that SourceBuffer, around the same position we were in when the switch was done.

Nothing out of the ordinary for now, the track switch audibly happens and Firefox seems happy.

Now, if I just seek to an unbuffered part, both of those players will push segments of that new track to the corresponding position. And that's where the problem happens....

Actual results:

When doing that, Firefox seems to consider those new segments as "empty" ( SourceBuffer.prototype.buffered tells us that no segment was pushed here and decoding does not continue), as if (and this is an hypothesis) it still relied on the track_id of the previous initialization segment (the one from the last track, so not the one from the last pushed initialization segment).

This hypothesis is consolidated by the fact that forcing the track_id from those new segments (in the tfhd ISOBMFF box) to the value of the track_id of the previous track resolve that issue (segments are not "empty" anymore, they now contain data).

Re-pushing the initialization segment before that segment fix the issue, but should not be needed - as the last initialization segment was the same one.

Expected results:

Firefox should always consider the last track_id of the last pushed initialization segment.

Other browsers (like Chromium and Chromium-derivatives on some embedded devices) does not have that issue.

Note that I'm not a video expert (I'm mainly a developer), so Firefox may be in the right here and the issue might be in the content, other browsers just being more resilient.

But multiple indicators, like the fact that the switch originally goes well or the fact that there's no issue if we re-push the same initialization segment works, make me believe that there is an issue in Firefox in that area.

The content I was testing on is sadly protected through DRM. If you want, I will try to find / generate a content with which you can reproduce that issue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jean-Yves Avenard [:jya]]

We do not support multiple audio source buffer on the same media element. And AFAIK no other browsers do

Additionally, per spec:
https://w3c.github.io/media-source/#sourcebuffer-init-segment-received

If more than one track for a single type are present (e.g., 2 audio tracks), then the Track IDs match the ones in the first initialization segment.

You can't change track Id half-way.

So if you had pushed an init segment where trackID=1 and now push an init segment where TrackID=2 on the same source buffer, it will cause an error.
So what you're probably seeing is that the media source is in error, and you can't add more data to it anymore.

Comment 3

[Jean-Yves Avenard [:jya]]

Any chances if you could send us some samples , like the init segment and a few media segments. It doesn't matter if they are encrypted.

It will be enough to reproduce the MSE buffered range issue you are referring to.

Comment 4

[Jean-Yves Avenard [:jya]]

I have the feeling that the bug is there:
https://searchfox.org/mozilla-central/source/dom/media/mediasource/TrackBuffersManager.cpp#1215-1220

We check if the audio configuration hasn't changed and ignore the init segment if so.

maybe the trackID isn't properly populated on the AudioInfo; IIRC the demuxer only ever parse the first track with MSE and always assume the trackID is 0.

Comment 5

[pea.berberian]

Hi, thanks for the quick answer.

We do not support multiple audio source buffer on the same media element. And AFAIK no other browsers do

Yes but I'm speaking about only one audio SourceBuffer here. When track switching occurs, the MSE player will just push its initialization segment on the same one and continue with its media segments.

Additionally, per spec:
https://w3c.github.io/media-source/#sourcebuffer-init-segment-received

If more than one track for a single type are present (e.g., 2 audio tracks), then the Track IDs match the ones in the first initialization segment.

I am under the impression that here the specification talk about a restriction when there's multiple track_id in a single initialization segment (the one that is being pushed) not when different initialization segments have a unique, though different between one another, track id (but maybe I misread, as I found the whole wording surrounding track id in that spec a little confusing).

So what you're probably seeing is that the media source is in error, and you can't add more data to it anymore.

I don't think that the MediaSource is on error after that, as I re-begin to play if I switch back the audio track.
Even when pushing the segments with the new track ids, that appears "empty" as I wrote, the whole append buffer process goes on normally (with "updateend" events and so on). So it makes me think that nothing is really wrong with the MediaSource's state but really Firefox is selecting the wrong track id (maybe that's a conclusion you also reached on your last comment).

---

Any chances if you could send us some samples , like the init segment and a few media segments. It doesn't matter if they are encrypted.
It will be enough to reproduce the MSE buffered range issue you are referring to.

As our contents may be geographically restricted, I re-uploaded it temporarily through github pages (I removed the encrypted video part as we don't care about that here, the rest is unencrypted).
There's a small complexity here, each track has only one segments which is a concatenation of a:

• initialization segment
• a sidx box (allowing to retrieve the byte ranges for the media segments)
• every media segments, one by one

So that may make tests more difficult to set-up.

Based on that, I propose here two means of testing:

1. You can either use the whole two audio tracks and try testing yourself (by e.g. splitting the file at the right byte-ranges).

   • The first audio track (with track_id 2): https://developers.canal-plus.com/rx-player/track_id_test/assets/testcanal.fr_20200914_SD_VM_ATM_OTT_SD_5_AACLC_20_VM_audio_64_aaclc_fre.mp4
   • The second audio track (with track_id 3): https://developers.canal-plus.com/rx-player/track_id_test/assets/testcanal.fr_20200914_SD_VM_ATM_OTT_SD_5_AACLC_20_VM_audio_65_aaclc_qaa.mp4

   For both, the initialization segment is at byte 0-615 included, the sidx box range is at 616-9107 included.

2. I made a demo page of the RxPlayer - which already does that task of splitting up the tracks and pushing segments to the SourceBuffer - playing that content at: https://developers.canal-plus.com/rx-player/track_id_test/index.html#!tech_4=DASH!manifest_2k=https://developers.canal-plus.com/rx-player/track_id_test/assets/test_multiple_track_ids.mpd
   Here, to reproduce, you can click the play button, change the track (gear button + "Audio Language") and seek.
   The behavior of the player here will be to re-download and re-push the problematic segment in a loop

Do not hesitate to comeback to me if another way of testing is more practical for you (like giving you specific byte ranges for specific segments).

---

I have the feeling that the bug is there:
https://searchfox.org/mozilla-central/source/dom/media/mediasource/TrackBuffersManager.cpp#1215-1220

We check if the audio configuration hasn't changed and ignore the init segment if so.

maybe the trackID isn't properly populated on the AudioInfo; IIRC the demuxer only ever parse the first track with MSE and always assume the trackID is 0.

It does look like if the new init segment is ignored at some point.

But strangely:

1. I did not reproduce when I re-pushed the initialization segment before any segment is pushed (so basically re-pushing the same over and over) and,
2. the issue only appear after some time after switching a track, or a seek (first segments can be appended and decoded just fine). Like if it re-initialized to the initial init segment at a given point in time.

Comment 6

[pea.berberian]

Hi,

Sorry for the bump but any news on that issue?

Knowing if this has been confirmed as a Firefox issue (or at least suspicions of it) and/or if a possible fix is under way will help us find the right solution on our side.

Comment 7

[Jean-Yves Avenard [:jya]]

The behaviour of the player is rather weird.

What I did was click play wait for playback to start, change the audio track (currentTime was around 5s) and seek to 20m37s.

Here is what I'm seeing in the log when clicking on play, followed by changing the track language and then seeking.
Note that in those logs, I can't se when the audio track is changed, as it's all done at the JS level. Firefox isn't aware of this.
Init segment is added
appendBuffer is called multiple-times, adding 4s of audio at a time, up to 12s, making the buffered range from 0 to 12.010666
appendBuffer is called, with 4s of audio from 0 to 4.010666s, so range is still 0 to 12.010666
appendBuffer is called multiple-times, adding audio from 12s to 16s, then 16s to 20s, 20s-24s, 24-28, 28-32.
appendBuffer is called with audio from 24-28 (why?), then 32 to 36
remove is called from 0 to 3.10s (at this time, the internal decoder is decoding frame at 7.168s ahead of currentTime), buffered range is now (3.114666, 36.010666)
remove is called from 7.600250s 36.010666s, buffered range is now (3.114666, 7.616000). The decoding stack is now stalled waiting for new audio.
AppendWindowEnd is set to +oo
init segment is appended
AppendWindowEnd is set to 2818.82s
appendBuffer is called with 4.010666 to 8s, then 8-12, 12-16, 16-20 (the buffered range is (3.114666, 24.000000))
at that point appendBuffer is called again, and this time we fail to retrieve data, they are read as empty but the start time of the media segment was 12s to 16s.
appendBuffer is called with data from 24-28s, 28-32, 32-36, 36-40, which we also fail to demux as they contain no frame of the current track id.
appendBuffer is called with 24-28, 28-32, 24-28, 32-36, 36-40, 24-28, 28-32, 32-36, 24-28, 28-32, 32-36, 36-40, 24-28, 28-32, 32-36. 36-40, 24-28, 28-32, all detected as empty.
seek to 1232485320us
appendBuffer with 1232.0, 1236.010666 etc, none are found to contain data.

Will need to add more logging to determine what track ID the init segment set and the track id found in the followup media segment.

Comment 8

[Jean-Yves Avenard [:jya]]

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

Comment 9

[Jean-Yves Avenard [:jya]]

(In reply to pea.berberian from comment #6)

Hi,

Sorry for the bump but any news on that issue?

Knowing if this has been confirmed as a Firefox issue (or at least suspicions of it) and/or if a possible fix is under way will help us find the right solution on our side.

This is indeed a firefox bug.

What I can suggest you do in the mean time, is before sending a new init segment, call abort() (https://w3c.github.io/media-source/#dom-sourcebuffer-abort) ; this will force the re-creation of the demuxers.

This solution will work with all browsers too ; we likely never saw that bug before because most players would send abort before sending a new init segment ; as it makes it easier to deal with partial media segment.

Edit: it's actually not going to work, ignore this.

What could work is send a dummy init segment significantly different to the first one (like using a different sampling rate or number of channels) ; and then send the actual init info you want.

Comment 10

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1679283 - P1. Add test. r?bryce

Comment 11

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1679283 - P2. Always store the init segment just appended. r=bryce!,alwu!

different init segment may yield the same AudioInfo object; so we can't rely on the AudioInfo value to determine if we should use the new init segment or not.

Depends on D98874

Comment 12

[Jean-Yves Avenard [:jya]]

I'm not sure why the OP only saw the issue after seeking, because it's definitely always a problem. See test in P1.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/489d44c5eb47
P1. Add test. r=bryce,alwu
https://hg.mozilla.org/integration/autoland/rev/f4f27247a27c
P2. Always store the init segment just appended. r=bryce,alwu

Comment 14

[Bogdan Tara[:bogdan_tara | bogdant]]

Backed out 2 changesets (bug 1679283) for segment related bustage.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=build&fromchange=f4f27247a27c0f54bbe3e0b372c1195ce624b66c&tochange=30edbad227262ff147f825743476d08292042cdc&selectedTaskRun=HINyHqFaQR6pMf6JGcP2ig.0

Backout link: https://hg.mozilla.org/integration/autoland/rev/30edbad227262ff147f825743476d08292042cdc

Failure log: https://treeherder.mozilla.org/logviewer?job_id=323846779&repo=autoland&lineNumber=1280

[task 2020-12-08T01:28:29.420Z] 01:28:29     INFO -  Reticulating splines...
[task 2020-12-08T01:28:30.571Z] 01:28:30     INFO -   0:01.18 File already read. Skipping: /builds/worker/checkouts/gecko/gfx/angle/targets/angle_common/moz.build
[task 2020-12-08T01:28:31.343Z] 01:28:31    ERROR -  Traceback (most recent call last):
[task 2020-12-08T01:28:31.343Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1865, in _process_test_manifest
[task 2020-12-08T01:28:31.343Z] 01:28:31     INFO -      process_support_files(m_defaults)
[task 2020-12-08T01:28:31.343Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1822, in process_support_files
[task 2020-12-08T01:28:31.343Z] 01:28:31     INFO -      test, install_root, manifest_dir, out_dir
[task 2020-12-08T01:28:31.344Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/testing.py", line 138, in convert_support_files
[task 2020-12-08T01:28:31.344Z] 01:28:31     INFO -      " please omit the duplicate entry." % (pattern, field)
[task 2020-12-08T01:28:31.344Z] 01:28:31     INFO -  ValueError: segment-2.0001.m4s appears multiple times in a test manifest under a support-files field, please omit the duplicate entry.
[task 2020-12-08T01:28:31.344Z] 01:28:31     INFO -  During handling of the above exception, another exception occurred:
[task 2020-12-08T01:28:31.345Z] 01:28:31    ERROR -  Traceback (most recent call last):
[task 2020-12-08T01:28:31.345Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/configure.py", line 231, in <module>
[task 2020-12-08T01:28:31.345Z] 01:28:31     INFO -      sys.exit(main(sys.argv))
[task 2020-12-08T01:28:31.345Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/configure.py", line 85, in main
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -      return config_status(config)
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/configure.py", line 226, in config_status
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -      return config_status(args=[], **sanitized_config)
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/config_status.py", line 174, in config_status
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -      definitions = list(definitions)
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 180, in emit
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -      objs = list(emitfn(out))
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1593, in emit_from_context
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -      for obj in self._process_test_manifests(context):
[task 2020-12-08T01:28:31.346Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1768, in _process_test_manifests
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -      for obj in self._process_test_manifest(context, info, path, manifest):
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1897, in _process_test_manifest
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -      context,
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -  mozbuild.frontend.reader.SandboxValidationError:
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -  ==============================
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -  FATAL ERROR PROCESSING MOZBUILD FILE
[task 2020-12-08T01:28:31.347Z] 01:28:31     INFO -  ==============================
[task 2020-12-08T01:28:31.348Z] 01:28:31     INFO -  The error occurred while processing the following file or one of the files it includes:
[task 2020-12-08T01:28:31.348Z] 01:28:31     INFO -      /builds/worker/checkouts/gecko/dom/media/mediasource/moz.build
[task 2020-12-08T01:28:31.348Z] 01:28:31     INFO -  The error occurred when validating the result of the execution. The reported error is:
[task 2020-12-08T01:28:31.348Z] 01:28:31    ERROR -      Error processing test manifest file /builds/worker/checkouts/gecko/dom/media/mediasource/test/mochitest.ini: Traceback (most recent call last):
[task 2020-12-08T01:28:31.349Z] 01:28:31     INFO -        File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1865, in _process_test_manifest
[task 2020-12-08T01:28:31.349Z] 01:28:31     INFO -          process_support_files(m_defaults)
[task 2020-12-08T01:28:31.349Z] 01:28:31     INFO -        File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/frontend/emitter.py", line 1822, in process_support_files
[task 2020-12-08T01:28:31.349Z] 01:28:31     INFO -          test, install_root, manifest_dir, out_dir
[task 2020-12-08T01:28:31.349Z] 01:28:31     INFO -        File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/testing.py", line 138, in convert_support_files
[task 2020-12-08T01:28:31.350Z] 01:28:31     INFO -          " please omit the duplicate entry." % (pattern, field)
[task 2020-12-08T01:28:31.350Z] 01:28:31     INFO -      ValueError: segment-2.0001.m4s appears multiple times in a test manifest under a support-files field, please omit the duplicate entry.
[task 2020-12-08T01:28:33.497Z] 01:28:33     INFO -  Error running mach:
[task 2020-12-08T01:28:33.497Z] 01:28:33     INFO -      ['--log-no-times', 'build', '-v']
[task 2020-12-08T01:28:33.498Z] 01:28:33     INFO -  The error occurred in code that was called by the mach command. This is either
[task 2020-12-08T01:28:33.498Z] 01:28:33     INFO -  a bug in the called code itself or in the way that mach is calling it.
[task 2020-12-08T01:28:33.498Z] 01:28:33     INFO -  You can invoke |./mach busted| to check if this issue is already on file. If it
[task 2020-12-08T01:28:33.498Z] 01:28:33     INFO -  isn't, please use |./mach busted file build| to report it. If |./mach busted| is
[task 2020-12-08T01:28:33.499Z] 01:28:33     INFO -  misbehaving, you can also inspect the dependencies of bug 1543241.
[task 2020-12-08T01:28:33.499Z] 01:28:33     INFO -  If filing a bug, please include the full output of mach, including this error
[task 2020-12-08T01:28:33.499Z] 01:28:33     INFO -  message.
[task 2020-12-08T01:28:33.499Z] 01:28:33     INFO -  The details of the failure are as follows:
[task 2020-12-08T01:28:33.499Z] 01:28:33     INFO -  Exception: Process executed with non-0 exit code 1: ['/builds/worker/workspace/obj-build/_virtualenvs/init_py3/bin/python', '/builds/worker/checkouts/gecko/configure.py']
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/build_commands.py", line 153, in build
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -      append_env=append_env,
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/controller/building.py", line 1144, in build
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -      append_env=append_env,
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/controller/building.py", line 1528, in configure
[task 2020-12-08T01:28:33.500Z] 01:28:33     INFO -      append_env=append_env,
[task 2020-12-08T01:28:33.501Z] 01:28:33     INFO -    File "/builds/worker/checkouts/gecko/python/mozbuild/mozbuild/base.py", line 887, in _run_command_in_objdir
[task 2020-12-08T01:28:33.501Z] 01:28:33     INFO -      return self.run_process(cwd=self.topobjdir, **args)
[task 2020-12-08T01:28:33.501Z] 01:28:33     INFO -    File "/builds/worker/checkouts/gecko/python/mach/mach/mixin/process.py", line 177, in run_process
[task 2020-12-08T01:28:33.501Z] 01:28:33     INFO -      "Process executed with non-0 exit code %d: %s" % (status, args)
[task 2020-12-08T01:28:33.541Z] 01:28:33    ERROR - Return code: 1
[task 2020-12-08T01:28:33.541Z] 01:28:33  WARNING - setting return code to 2
[task 2020-12-08T01:28:33.542Z] 01:28:33    FATAL - 'mach build -v' did not run successfully. Please check log for errors.
[task 2020-12-08T01:28:33.542Z] 01:28:33    FATAL - Running post_fatal callback...
[task 2020-12-08T01:28:33.542Z] 01:28:33    FATAL - Exiting -1
[task 2020-12-08T01:28:33.542Z] 01:28:33     INFO - [mozharness: 2020-12-08 01:28:33.542135Z] Finished build step (failed)

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/17f32b48d8f9
P1. Add test. r=bryce,alwu
https://hg.mozilla.org/integration/autoland/rev/0118788649e7
P2. Always store the init segment just appended. r=bryce,alwu

Comment 16

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/17f32b48d8f9
https://hg.mozilla.org/mozilla-central/rev/0118788649e7

Comment 17

[pea.berberian]

The behaviour of the player is rather weird.

It might deserve more investigation for a correct answer but cases where segments are re-downloaded (sometimes in a loop, like you had) typically happen when the player thinks that a segment it has pushed has since been garbage collected, either partially or fully. They are for some occurrences not exclusive to the RxPlayer.
The segment request in a loop behavior for example is also encountered with the same content with the shaka-player (not to accuse them also! Just to explain why you might observe that weird behavior and why it may make sense in most situations).

Updates of append windows happens in some instances linked to how DASH works, difficult to say which one you encountered here, but it doesn't look too abnormal in your description.

There is also the fact that you switched track. After that there is a combination of segment removal (segments from the old track) and segment replacement as a default (configurable) behavior in the RxPlayer.

Plus the fact that there is "fast-switching" on by default: segments with a better quality can replace segments with a lower quality under some conditions. So multiple reasons for pushing segments on "top of" previously already-buffered parts.

the issue is with the check if ...

The problem description information, code links and possible solution was really informative and interesting, thanks!
Made me want to learn more about Firefox's MSE implementation, I might dive in that code area later!

I'm not sure why the OP only saw the issue after seeking, because it's definitely always a problem. See test in P1.

I've seen in even regular playback, but like I wrote only after some time when no seek was performed:

the issue only appear after some time after switching a track, or a seek

As the issue was directly reproducible after a seek, I insisted on that point.

Comment 18

[pea.berberian]

Thanks a lot for the fix also!