Closed guest271314 closed 4 years ago
Example of the use case https://github.com/guest271314/MediaFragmentRecorder/edit/getdisplaymedia-pictureinpicture/MediaFragmentRecorder.html where it is not currently possible to resize PictureInPictureWindow
programmatically, for example, using resizeTo()
to match videoWidth
and videoHeight
of HTML pictureInPictureElement
for the expected output of using getDisplayMedia()
as a workaround for MediaRecorder
stopping per specification when HTML <video>
element src
is changed.
You can resize Picture-in-Picture window by adjusting video width and height. Give it a try at https://beaufortfrancois.github.io/sandbox/media/picture-in-picture-canvas
Does the capability exist to resize Picture-in-Picture widnow exceeding screen.width/2
to match the videoWidth
and videoHeight
of the source media? If not, why?
Why does the PictureInPictureWindow
not match the exact width
and height
set?
At the linked document when input is 400x300 output is 478x359.
The expected result is when input video has pixel dimensions 1280x720 PictureInPictureWindow
should be capable of rendering those exact dimensions. If the src
of the <video>
changes and the videoWidth
and videoHeight
are 768x576, it should be possible to set those properties directly programmatically.
@beaufortfrancois Must have not updated the branch at the above link at https://github.com/w3c/picture-in-picture/issues/163#issuecomment-522192465. Updated now with Picture-in-Picture code.
This would be a very great feature to have. I'd love to not resort to canvas hacks to achieve such a simple functionality.
It seems like a Chrome issue rather an a spec issue. Let's continue this conversation at https://bugs.chromium.org/p/chromium/issues/detail?id=937859
@beaufortfrancois It is a specification issue because of this language
It is also RECOMMENDED that the Picture-in-Picture window has a maximum and minimum size. For example, it could be restricted to be between a quarter and a half of one dimension of the screen.
which can be removed from the specification given that multiple parties have now expressed the interpretation of that recommendation by Chromium implementers is limiting use cases perhaps not conceived of by the specification authors, or in any event will not cause any issue that might have been conceived by not recommending arbitrary limitations on picture in picture window..
PR https://github.com/w3c/picture-in-picture/pull/186 for clarity.
Will pursue at https://github.com/w3c/picture-in-picture/pull/186!
@beaufortfrancois
This issue needs to be re-opened.
So far nobody has explained or provided any reason either in this Issue or the PR or in the Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=937859#c18 why this language
It is also RECOMMENDED that the Picture-in-Picture window has a maximum and
minimum size. For example, it could be restricted to be between a quarter and a half of one dimension of the screen.
is in the specification.
I'd also like to ask as to why there is a recommendation to implement a maximum size.
From the closed PR (#186)
This suggestion comes from the experience of platforms and browsers implementing Picture-in-Picture (either the Web API or another sort).
How can this possibly be used as justification, when the limit has always been in place? Furthermore the Firefox equivalent does not implement this limitation. The chromium bug (here) was also closed without any justification, besides mlamouri's comment:
I do not believe we should re-visit this decision on anecdata. We believe that the size limitations match the use cases. We could add metrics to check what is the usual window size. Maybe it ends up mostly at its maximum size which would be a good signal.
These use cases are never actually elaborated on. I also note that this same person closed both that bug report with WontFix and #186 (I would comment there instead of here if that hadn't been locked).
It seems to mostly boil down to a member of the Chromium team believing there should be a limit, and therefore the limit should exist.
PiP is essentially just an always on top video player. Would you expect a desktop video player to limit size when in always on top mode (mpv, vlc etc)? They can, as should be expected, be resized at will, and even full-screened. The only possible reasoning I can think of for this limit is to stop a web page requesting an overly large size. This is sensible, and I would agree with a recommendation that suggests limiting initial size, but limiting resizing for the user is unwarranted.
Located this issue from
The title of the linked Chrome issue https://bugs.chromium.org/p/chromium/issues/detail?id=949570 does not contain the language of this feature request. To avoid confusion, filing this issue for clarity.
Note, it is not immediately obvious that the
PictureInPicture
window
can be resized by user action.It is apparently also not specified or possible by means of a workaround that have yet succeeded to resize
PictureInPicture
window
programmatically. Persisting a user-resized Picture-in-Picture window requires running the code twice to begin recording at the maximumwidth
or awaitpictureInPicture.width === screen.width/2
withinresize
event, then proceed, which is not necessarily possible for each attempt due to the implementation of the resized window, where the output should be met at the first attempt, without awaiting executingrequestPictureInPicture()
twice orwidth
andheight
values atresize
event initiated by user action.(Though beyond the scope of this specific issue it should also be possible to resize Picture-in-Picture to fullscreen)
The use case for setting
width
andheight
of Picture-in-Picture programmatically, without user action, is recordingPictureInPicture
window
, to utilize the unique playback capabilities of the Picture-in-Picture window.