Bugzilla

So far I've done some improvement on bug 1717119, bug 1718309 and bug 1718709, but they didn't seem to help on the performance test directly. So I started to check the test itself today again, and found out that the new mechanism that is used to skip to next keyframe if playback is late is the root cause for performance degrade while playing `testsrc.1080p.60fps.mp4` in `video_playback.html`.

For that video file, I found that we acutally pretty easy to hit the skip-to-next-keyframe, which means the decoded video is later than the audio clock. Now we use [the audio clock to determine whether the video is late](https://searchfox.org/mozilla-central/rev/e082df56bbfeaff0f388e7da9da401ff414df18f/dom/media/MediaDecoderStateMachine.cpp#595-597), but this is acutally incorrect. Although the audio clock is used to determine [whether the video is late](https://searchfox.org/mozilla-central/rev/e082df56bbfeaff0f388e7da9da401ff414df18f/dom/media/mediasink/VideoSink.cpp#495-510) in VideoSink, however, the audio clock is used to compare with the time of the first decoded video in the video queue, not the one which is just pushed into the video queue. So we need to modify that by just checking the media time, and also probably not to seek to the next frame too aggressively.

So far I've done some improvement on bug 1717119, bug 1718309 and bug 1718709, but they didn't seem to help on the performance test directly. So I started to check the test itself today again, and found out that the new mechanism that is used to skip to next keyframe if playback is late is the root cause for performance degrade while playing `testsrc.1080p.60fps.mp4` in `video_playback.html`.

For that video file, I found that we acutally pretty easy to hit the skip-to-next-keyframe, which means the decoded video is later than the audio clock. Now we use [the audio clock to determine whether the video is late](https://searchfox.org/mozilla-central/rev/e082df56bbfeaff0f388e7da9da401ff414df18f/dom/media/MediaDecoderStateMachine.cpp#595-597), which is similar with what we did in the [VideoSink](https://searchfox.org/mozilla-central/rev/e082df56bbfeaff0f388e7da9da401ff414df18f/dom/media/mediasink/VideoSink.cpp#495-510). However, we should only check the media time in the MDSM, and only let VideoSink to use the audio clock. Because if we seek to the next frame too aggresively, which means once there is one dropped frame, the video would jump to the next key frame directly which might cause some video freeze if the key frame has longer interval.