Paul, Matthew, there are more media profiles indicating the issue is caused by **unstable audio clock**. Eg 1 (comment 29, with ublock) At `28.192s`, the last time video sink received [a new frame](https://share.firefox.dev/45oj1lY), it still had 4 frames in the queue, and the queue constantly had 4 frames most of the time, which indicates that the decoding speed is stable. By checking [MFR](https://share.firefox.dev/3VIAJ0x), we can know `23,232,000μs` is the last video frame. In video sink, we can also observe that when video sink rendered the last frame, we still have [4 frames in the queue](https://share.firefox.dev/3RrIQf4). However, at `28.347s` MDSM suddenly entered the [buffering state](https://share.firefox.dev/4cksMnK) due to `OutOfDecodedVideo`. That was very unreasonable, where were those 4 frames in the queue? So I checked the [audio clock](https://share.firefox.dev/4ej6FQj) and noticed that audio clock grew incorrectly! At `28.347s` audio clock was `Getting position from the Audio Sink 23.270520`, but at `28.348s` it suddenly became `Getting position from the Audio Sink 23.283500`. It increased `0.01298s` within `0.001s`, which was 10 times larger than it should grow. I think that made [video sink to discard remaining 4 frames in the queue](https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/dom/media/mediasink/VideoSink.cpp#515) because they are already "LATE" to the audio clock. Eg 2 (comment 29, without ublock) You can observe same situation in [here](https://share.firefox.dev/4cmtfWb). At `18.833s` and `18.834s` audio clock grew `0.018208s` within `0.001s`, which is also 10 times more than it should grow. Eg 3 (comment 32, the second profile) Same situaition [here](https://share.firefox.dev/3VhGMaO), at `12.194s` and `12.199s`, the audio clock grew `0.03715s` within `0.005s`.
Bug 1878510 Comment 33 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Paul, Matthew, there are more media profiles indicating the issue is caused by **unstable audio clock**. Eg 1 (comment 29, with ublock) At `28.192s`, the last time video sink received [a new frame](https://share.firefox.dev/45oj1lY), it still had 4 frames in the queue, and the queue constantly had 4 frames most of the time, which indicates that the decoding speed is stable. By checking [MFR](https://share.firefox.dev/3VIAJ0x), we can know `23,232,000μs` is the last video frame. In video sink, we can also observe that when video sink rendered the last frame, we still have [4 frames in the queue](https://share.firefox.dev/3RrIQf4). However, at `28.347s` MDSM suddenly entered the [buffering state](https://share.firefox.dev/4cksMnK) due to `OutOfDecodedVideo`. That was very unreasonable, where were those 4 frames in the queue? So I checked the [audio clock](https://share.firefox.dev/4ej6FQj) and noticed that audio clock grew incorrectly! At `28.347s` audio clock was `Getting position from the Audio Sink 23.270520`, but at `28.348s` it suddenly became `Getting position from the Audio Sink 23.283500`. It increased `0.01298s` within `0.001s`, which was 10 times larger than it should grow. I think that made [video sink to discard remaining 4 frames in the queue](https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/dom/media/mediasink/VideoSink.cpp#515) because they are already "LATE" to the audio clock. Eg 2 (comment 29, without ublock) You can observe same situation [here](https://share.firefox.dev/4cmtfWb). At `18.833s` and `18.834s` audio clock grew `0.018208s` within `0.001s`, which is also 10 times more than it should grow. Eg 3 (comment 32, the second profile) Same situaition [here](https://share.firefox.dev/3VhGMaO), at `12.194s` and `12.199s`, the audio clock grew `0.03715s` within `0.005s`.
Paul, Matthew, there are more media profiles indicating the issue is caused by **unstable audio clock**. Eg 1 (comment 29, with ublock) At `28.192s`, the last time video sink received [a new frame](https://share.firefox.dev/45oj1lY), it still had 4 frames in the queue, and the queue constantly had 4 frames most of the time, which indicates that the decoding speed is stable. By checking [MFR](https://share.firefox.dev/3VIAJ0x), we can know `23,232,000μs` is the last video frame. In video sink, we can also observe that when video sink rendered the last frame, we still had [4 frames in the queue](https://share.firefox.dev/3RrIQf4). However, at `28.347s` MDSM suddenly entered the [buffering state](https://share.firefox.dev/4cksMnK) due to `OutOfDecodedVideo`. That was very unreasonable, where were those 4 frames in the queue? So I checked the [audio clock](https://share.firefox.dev/4ej6FQj) and noticed that audio clock grew incorrectly! At `28.347s` audio clock was `Getting position from the Audio Sink 23.270520`, but at `28.348s` it suddenly became `Getting position from the Audio Sink 23.283500`. It increased `0.01298s` within `0.001s`, which was 10 times larger than it should grow. I think that made [video sink to discard remaining 4 frames in the queue](https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/dom/media/mediasink/VideoSink.cpp#515) because they are already "LATE" to the audio clock. Eg 2 (comment 29, without ublock) You can observe same situation [here](https://share.firefox.dev/4cmtfWb). At `18.833s` and `18.834s` audio clock grew `0.018208s` within `0.001s`, which is also 10 times more than it should grow. Eg 3 (comment 32, the second profile) Same situaition [here](https://share.firefox.dev/3VhGMaO), at `12.194s` and `12.199s`, the audio clock grew `0.03715s` within `0.005s`.
Paul, Matthew, there are more media profiles indicating the issue is caused by **unstable audio clock**. Eg 1 (comment 29, with ublock) At `28.192s`, the last time video sink received [a new frame](https://share.firefox.dev/45oj1lY), it still had 4 frames in the queue, and the queue constantly had 4 frames most of the time, which indicates that the decoding speed is stable. By checking [MFR](https://share.firefox.dev/3VIAJ0x), we can know `23,232,000μs` is the last video frame. In video sink, we can also observe that when video sink rendered the last frame, we still had [4 frames in the queue](https://share.firefox.dev/3RrIQf4). However, at `28.347s` MDSM suddenly entered the [buffering state](https://share.firefox.dev/4cksMnK) due to `OutOfDecodedVideo`. That was very unreasonable, where were those 4 frames in the queue? So I checked the [audio clock](https://share.firefox.dev/4ej6FQj) and noticed that audio clock grew incorrectly! At `28.347s` audio clock was `Getting position from the Audio Sink 23.270520`, but at `28.348s` it suddenly became `Getting position from the Audio Sink 23.283500`. It increased `0.01298s` within `0.001s`, which was 10 times larger than what it should grow. I think that made [video sink to discard remaining 4 frames in the queue](https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/dom/media/mediasink/VideoSink.cpp#515) because they are already "LATE" to the audio clock. Eg 2 (comment 29, without ublock) You can observe same situation [here](https://share.firefox.dev/4cmtfWb). At `18.833s` and `18.834s` audio clock grew `0.018208s` within `0.001s`, which is also 10 times more than it should grow. Eg 3 (comment 32, the second profile) Same situaition [here](https://share.firefox.dev/3VhGMaO), at `12.194s` and `12.199s`, the audio clock grew `0.03715s` within `0.005s`.