Feature Request: Use Document Picture-in-Picture Web API about rx-player HOT 2 OPEN

Hi @beaufortfrancois and thanks for reaching out for this browser update!

The feature looks nicer than the current API as we now will be able to also integrate subtitles and even some of the application's UI in the window.

Though I checked and didn't see support for other browsers than Chrome (the spec seems to be an "Unofficial Proposal Draft" and its Chrome Platform Status page indicates "no signal" and even some reticences from other vendors). Is there incoming updates to the API to reach a consensus? I would prefer a browser-independent solution.

Also, I think that in a RxPlayer context, it will be the role of the application (who integrates the RxPlayer) to actually rely on such API so it can decide what to put in it.

However, the RxPlayer might want to detect when a pip window containing the video element is displayed for two reasons:

• the throttleVideoBitrateWhenHidden option throttles the video bitrate when the video is not visible for more than a minute. Normally, we use the page visibility APIs for this, but the Picture-In-Picture modes now forces us to be a little more clever.

  For that one, I guess we have to check when a PiP window containing the media element is loaded or unloaded. From what I understand, I can check on the documentPictureInPicture's "enter" event that a PiP window has been enabled and then I can check that the media element is inside of it.
  However, for the closing part, I'm not sure, does the corresponding PictureInPictureWindow's "unload" event catches all cases of the PiP window being closed?
  Also there's the condition where we need to check that the media element is added removed from a still-active PiP window (such as the PiP window is still active, but the media element is back to the regular Window's DOM, or the other way around) where I'm unsure of what the most practical way would be.

• similar, the limitVideoWidth option restricts the video quality according to the video element's width. Here it's not the size of the PiP window that is to interest to us, but of the video element.
  Here the main interrogation is: if we keep the old reference to the video element before it was inserted in a PictureInPictureWindow, do we still get updates from a ResizeObserver? Do the clientWidth and clientHeight attributes are updated accordingly to its dimensions inside the PictureInPictureWindow?

from rx-player.

Hi @beaufortfrancois and thanks for reaching out for this browser update!

The feature looks nicer than the current API as we now will be able to also integrate subtitles and even some of the application's UI in the window.

Exactly! 🥳

Though I checked and didn't see support for other browsers than Chrome (the spec seems to be an "Unofficial Proposal Draft" and its Chrome Platform Status page indicates "no signal" and even some reticences from other vendors). Is there incoming updates to the API to reach a consensus? I would prefer a browser-independent solution.

The Chrome team is the one proposing this API based on feedback we’ve received from the Picture-in-Picture API for <video>. It will follow the usual path for standardization. As you saw, we’ve started engaging with Firefox and Apple folks respectively at mozilla/standards-positions#670 and WebKit/standards-positions#41 and from where I stand, we’re still discussing and will hopefully reach consensus. The origin trial is actually part of these efforts as web developers feedback is key there.

Also, I think that in a RxPlayer context, it will be the role of the application (who integrates the RxPlayer) to actually rely on such API so it can decide what to put in it.

However, the RxPlayer might want to detect when a pip window containing the video element is displayed for two reasons:

• the throttleVideoBitrateWhenHidden option throttles the video bitrate when the video is not visible for more than a minute. Normally, we use the page visibility APIs for this, but the Picture-In-Picture modes now forces us to be a little more clever.
  For that one, I guess we have to check when a PiP window containing the media element is loaded or unloaded. From what I understand, I can check on the documentPictureInPicture's "enter" event that a PiP window has been enabled and then I can check that the media element is inside of it.

Yes. You can also check at any time whether documentPictureInPicture.window is null.

However, for the closing part, I'm not sure, does the corresponding PictureInPictureWindow's "unload" event catches all cases of the PiP window being closed?

Yes.

Also there's the condition where we need to check that the media element is added removed from a still-active PiP window (such as the PiP window is still active, but the media element is back to the regular Window's DOM, or the other way around) where I'm unsure of what the most practical way would be.

Would MutationObserver work for you?

• similar, the limitVideoWidth option restricts the video quality according to the video element's width. Here it's not the size of the PiP window that is to interest to us, but of the video element.

Is it safe to assume the video size covers 100% of the PiP window size?

Here the main interrogation is: if we keep the old reference to the video element before it was inserted in a PictureInPictureWindow, do we still get updates from a ResizeObserver?
Do the clientWidth and clientHeight attributes are updated accordingly to its dimensions inside the PictureInPictureWindow?

I’ve just tried it and I still get updates from a ResizeObserver observing the video before and entering PiP. clientWidth and clientHeight are updated properly as well.

const resizeObserver = new ResizeObserver((entries) => {
  console.log(`New size: ${entries[0].target.clientWidth}x${entries[0].target.clientHeight}`);
});
resizeObserver.observe(document.querySelector('video'));

from rx-player.