When we resume decoding when the video becomes visible, we would start a `video-only-seek` and would like to set the `timeThreshold`, which is used to control droping frame in demuxer [1], to the current clock or next available key frame time [2]. However, as the only key frame of this file [3] is the first frame, so when we start request video data from non-start position, all the other frames which are non-keyframes would be discarded, which would result in getting video's `EOS`. In this bug, when we resume decoding for `1FHQ2.webm`, it goes to the `decoding` state after finishing seeking, but we stuck there and didn't go to `completed` state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping. So what will happen after we getting video `EOS`? If the media contains audio, you would see that the video frame is freezing but the audio is still playing. You can reproduce this situation by playing `gizmo-noaudio.webm` [4] when resuming the video from suspending decoding. If the media doesn't contain audio, it should be stopped immediately because the decoding has been ended. [1] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaFormatReader.cpp#2514-2528 [2] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#1734-1752 [3] https://mltshp.com/r/1FHQ2.webm [4] dom/media/test/gizmo-noaudio.webm --- In this bug, when we resume decoding for `1FHQ2.webm`, it goes to the `decoding` state after finishing seeking, but we stuck there and didn't go to `completed` state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping. The reason we stuck is because the incorrect checking prevents us changing the state [5], this case only works for seamless looping, because seamless looping doesn't need to go through `completed` state, it can restart decoding by itself. The normal looping process is that, goes to `completed` state first, notify playback ended, and finally media element would call seek to the start position. However, seamless looping can stay in `loopingDecoding` state and repeating the looping without going to other states. [5] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#2281-2287
Bug 1532495 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
When we resume decoding when the video becomes visible, we would start a `video-only-seek` and would like to set the `timeThreshold`, which is used to control droping frame in demuxer [1], to the current clock or next available key frame time [2]. However, as the only key frame of this file [3] is the first frame, so when we start request video data from non-start position, all the other frames which are non-keyframes would be discarded, which would result in getting video's `EOS`. In this bug, when we resume decoding for `1FHQ2.webm`, it goes to the `decoding` state after finishing seeking, but we stuck there and didn't go to `completed` state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping. So what will happen after we get video `EOS`? If the media contains audio, you would see that the video frame is freezing but the audio is still playing. You can reproduce this situation by playing `gizmo-noaudio.webm` [4] when resuming the video from suspending decoding. If the media doesn't contain audio, it should be stopped immediately because the decoding has been ended. [1] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaFormatReader.cpp#2514-2528 [2] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#1734-1752 [3] https://mltshp.com/r/1FHQ2.webm [4] dom/media/test/gizmo-noaudio.webm --- In this bug, when we resume decoding for `1FHQ2.webm`, it goes to the `decoding` state after finishing seeking, but we stuck there and didn't go to `completed` state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping. The reason we stuck is because the incorrect checking prevents us changing the state [5], this case only works for seamless looping, because seamless looping doesn't need to go through `completed` state, it can restart decoding by itself. The normal looping process is that, goes to `completed` state first, notify playback ended, and finally media element would call seek to the start position. However, seamless looping can stay in `loopingDecoding` state and repeating the looping without going to other states. [5] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#2281-2287