Per this, I will do a follow-up to improve the readability of condition of isNextVideoBehindTheThreshold.

Also, we should enable buffering more video frames only on 4K+ video in order to prevent issue likg bug 1716638.

Improve the readability of the check and remove the next key frame check for the internal seek target because it's not related.

For lower resolution videos, we should be able to decode them well without storing too many video frames. So let's keep this mechanism for 4k+ video only.

Depends on D118401

Buffering more aggressively only for 4k makes sense. To make sure I'm following correctly, only buffering 4k will help with bug 1716638 for YouTube, as YT won't serve h264 at those resolutions, but we could still hit the issue if we get 4k+ h264 elsewhere and end up needing large buffers of frames. Is that correct?

Not elsewhere, that issue only happens on H264 + VAAPI (and only when the amount of stored frames is over the current threshold), and per this comment we could also increase the amount of frames ffmpeg buffered if someone uses H264 in 4K+.

Clarifying my elsewhere comment, I meant use cases outside of YouTube (if sites are doing high rest h264). It sounds like we have some other follow ups planned to address that case, and the plan isn't for this bug to cover all the cases.

Yes, I expect the bug 1716638 will raise the threshold of storing frames for the ffmpeg in order to address the issue for h264 4K+ video (if any)

https://hg.mozilla.org/mozilla-central/rev/a7f0f13b29ae
https://hg.mozilla.org/mozilla-central/rev/c16ded639f3e

I would like to inform you that my playback error was happened with VP9 + VAAPI as well, although bug 1716638 seems to be fixed with latest Nightly as with h264 + VAAPI.

Mentioned bugs still happen for me when playing 4K H.264 videos off YouTube (they exist). Not sure if closing them is correct.

Apologies. Correction: 4K VP9 videos off YouTube.

Filed bug 1718309 with example URL for 4k VP8/VP9.