I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated later to the new end of the new coded frames group, which was now `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened The problem happened when JS player started appending the data that range is `21.336000, 25.604000`, which overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then that would trigger a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
Bug 1707846 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000`, that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed. Therefore, the JS player needs to ](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated later to the new end of the new coded frames group, which was now `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened The problem happened when JS player started appending the data that range is `21.336000, 25.604000`, which overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then that would trigger a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000` that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed. Therefore, the JS player needs to I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000`, that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed. Therefore, the JS player needs to ](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated later to the new end of the new coded frames group, which was now `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened The problem happened when JS player started appending the data that range is `21.336000, 25.604000`, which overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then that would trigger a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000` that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place arond middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000` that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place around the middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated to the new end of the new coded code group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000` that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.
I did some investigation and I think that is JS player's issue. As Bryce said in comment3, there was a gap between `25.604` and `29.87`, and that missing part was removed by MSE spec, so the JS player should be responsible to add them back. --- Let's go through the process steps by steps, 1. seeked to near the end and got the buffered range like that ``` Video : (25.603000, 29.869000), (29.870000, 30.036000) Audio : (25.594000, 30.544000) ``` 2. seeked to the place around the middle part of the video, and we would got the new buffeded range ``` Video : (12.803000, 17.069000), (25.603000, 29.869000), (29.870000, 30.036000) Audio : (12.794000, 17.060000), (25.594000, 30.544000) ``` When appending the data that belongs to the range of 12s to 17s, we detected the [discontinuty](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1875) that caused us to [reset the state](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#1891-1896) per [the spec step 6](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing). So here we reset the `highest end timestamp` for track buffer, which was `30.036000` for video and `30.544000` for audio, and that would be updated later to the new end of the new coded frames group, which was `17.069000` for video and `17.060000` for audio. 3. Video was continually playing, then something happened When JS player started appending the data which range is `21.336000, 25.604000` that overlapped with the previous data `(25.603000, 29.869000)` that had been appended. Then triggered a process of [removing frames](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/dom/media/mediasource/TrackBuffersManager.cpp#2151-2153). Per [the spec step14](https://w3c.github.io/media-source/#sourcebuffer-coded-frame-processing), > If highest end timestamp for track buffer is set and less than or equal to presentation timestamp, > => Remove all coded frames from track buffer that have a presentation timestamp greater than or equal to highest end timestamp and less than frame end timestamp According to the step2, the `highest end timestamp` had been reset before, so currently the `highest end timestamp` was `25.604000`. All coded frames have a presentation timestamp greater than or equal to `25.604000` would be removed.