Bug 1947814 - Ensure that we continue to issue video frame request callbacks after seeking. r=media-playback-reviewers,alwu

When a video completes, we can present the first frame again, with its
original first frame ID. We tried to fix this by filtering for earlier
frames which should generally work since we redecode after a seek.

But if the seek produces earlier frames as well, then we can
unexpectedly suppress those video frame request callbacks. As such, we
now track how many frames have been presented separately from the frame
ID. If we have never seeked, then these values will always been the
same. Otherwise we will diverge in order to maintain the monotonically
increasing requirement.

Differential Revision: https://phabricator.services.mozilla.com/D239944

Author: aosmond

dom/html/HTMLVideoElement.cpp

@@ -744,7 +744,7 @@ void HTMLVideoElement::TakeVideoFrameRequestCallbacks(
   // If all of the available images are for future compositions, we must have
   // fired too early. Wait for the next invalidation.
   if (!selected || selected->mFrameID == layers::kContainerFrameID_Invalid ||
-      selected->mFrameID <= mLastPresentedFrameID) {
+      selected->mFrameID == mLastPresentedFrameID) {
     return;
   }
 
@@ -831,14 +831,27 @@ void HTMLVideoElement::TakeVideoFrameRequestCallbacks(
   }
 #endif
 
+  // Note that if we seek, or restart a video, we may present an earlier frame
+  // that we already presented with the same ID. This would cause presented
+  // frames to go backwards when it must be monotonically increasing. Presented
+  // frames cannot simply increment by 1 each request callback because it is
+  // also used by the caller to determine if frames were missed. As such, we
+  // will typically use the difference between the current frame and the last
+  // presented via the callback, but otherwise assume a single frame due to the
+  // seek.
+  mPresentedFrames +=
+      selected->mFrameID > 1 && selected->mFrameID > mLastPresentedFrameID
+          ? selected->mFrameID - mLastPresentedFrameID
+          : 1;
+  mLastPresentedFrameID = selected->mFrameID;
+
   // Presented frames is a bit of a misnomer from a rendering perspective,
   // because we still need to advance regardless of composition. Video elements
   // that are outside of the DOM, or are not visible, still advance the video in
   // the background, and presumably the caller still needs some way to know how
   // many frames we have advanced.
-  aMd.mPresentedFrames = selected->mFrameID;
+  aMd.mPresentedFrames = mPresentedFrames;
 
-  mLastPresentedFrameID = selected->mFrameID;
   mVideoFrameRequestManager.Take(aCallbacks);
 
   NS_DispatchToMainThread(NewRunnableMethod(

dom/html/HTMLVideoElement.h

@@ -202,6 +202,7 @@ class HTMLVideoElement final : public HTMLMediaElement {
   VideoFrameRequestManager mVideoFrameRequestManager;
   layers::ContainerFrameID mLastPresentedFrameID =
       layers::kContainerFrameID_Invalid;
+  uint32_t mPresentedFrames = 0;
 
  public:
   uint32_t RequestVideoFrameCallback(VideoFrameRequestCallback& aCallback,