I took a quick look on the profile provided in the comment 8, and found some weird points. First, in this profile, only ONE seek was performed at `13.047s` to the position `2327000`, then I started observing what happened after that. I noticed some unusual calls for `RemoveFrames` in the `MediaSupervisor` threads. Usually, the frame removal would be done either by (1) website's decision via calling MSE API, or (2) remove [old frames](https://searchfox.org/mozilla-central/rev/6bc0f370cc459bf79e1330ef74b21009a9848c91/dom/media/mediasource/TrackBuffersManager.cpp#2229-2253) which we no longer need. However, those `RemoveFrames` calls were removing the frames we just appended, which seems suspicious. Eg. From `13.932s` to `14.186s`, we appended vp9 continuously from `[2127000, 2189000]` to `[2753000, 2795000]`. Then we appended a `[0,0]` frame in `14.198s`, which also looks super suspicious. Also insert a `[3462000, 3504000]` at `14.367s`. Then the frame removal was triggered immediately at `14.367s` to remove `[3.462000, 417000]`. I'm guessing this issue would probably be caused by two reasons. (1) the video has incorrectly gap in between due to bad muxing (2) that `[0,0]` causes some unexpected frames removal, because that is unexpected to website, it would never know that they need to re-append those missing data. Anyway, this issue does require more investigation. Leave NI on myself for a further investigation.
Bug 1878510 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 took a quick look on the profile provided in the comment 8, and found some weird points. First, in this profile, only ONE seek was performed at `13.047s` to the position `2327000`, then I started observing what happened after that. I noticed some unusual calls for `RemoveFrames` in the `MediaSupervisor` threads. Usually, the frame removal would be done either by (1) website's decision via calling MSE API, or (2) remove [old frames](https://searchfox.org/mozilla-central/rev/6bc0f370cc459bf79e1330ef74b21009a9848c91/dom/media/mediasource/TrackBuffersManager.cpp#2229-2253) which we no longer need when appending new frames. However, those `RemoveFrames` calls were removing the frames we just appended, which seems suspicious. Eg. From `13.932s` to `14.186s`, we appended vp9 continuously from `[2127000, 2189000]` to `[2753000, 2795000]`. Then we appended a `[0,0]` frame in `14.198s`, which also looks super suspicious. Also insert a `[3462000, 3504000]` at `14.367s`. Then the frame removal was triggered immediately at `14.367s` to remove `[3.462000, 417000]`. I'm guessing this issue would probably be caused by two reasons. (1) the video has incorrectly gap in between due to bad muxing (2) that `[0,0]` causes some unexpected frames removal, because that is unexpected to website, it would never know that they need to re-append those missing data. Anyway, this issue does require more investigation. Leave NI on myself for a further investigation.
I took a quick look on the profile provided in the comment 8, and found some weird points. First, in this profile, only ONE seek was performed at `13.047s` to the position `2327000`, then I started observing what happened after that. I noticed some unusual calls for `RemoveFrames` in the `MediaSupervisor` threads. Usually, the frame removal would be done either by (1) website's decision via calling MSE API, or (2) remove [old frames](https://searchfox.org/mozilla-central/rev/6bc0f370cc459bf79e1330ef74b21009a9848c91/dom/media/mediasource/TrackBuffersManager.cpp#2229-2253) which we no longer need when appending new frames. However, those `RemoveFrames` calls were removing the frames we just appended, which seems suspicious. Eg. From `13.932s` to `14.186s`, we appended vp9 continuously from `[2127000, 2189000]` to `[2753000, 2795000]`. Then we appended a `[0,0]` frame in `14.198s`, which also looks super suspicious. Also insert a `[3462000, 3504000]` at `14.367s`. Then the frame removal was triggered immediately at `14.367s` to remove `[3.462000, 417000]`. I'm guessing this issue would probably be caused by two possible reasons. (1) the video has incorrectly gap in between due to bad muxing, or (2) that `[0,0]` causes some unexpected frames removal, because that is unexpected to website, it would never know that they need to re-append those missing data. Anyway, this issue does require more investigation. Leave NI on myself for a further investigation.