1574662 - Issue 994953: Feature Request: Include HTML <video> element wihin Window or Screen to share: Select Window or Screen menu at getDisplayMedia UI

Status: UNCONFIRMED

(Core :: WebRTC: Audio/Video, enhancement, P5)

Description

[guest271314]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

1. Execute getDisplayMedia()

Actual results:

1. HTML <video> elements are not listed at "Window or Screen to share: Select Window or Screen" menu UI.

Expected results:

1. HTML <video> elements listed at "Window or Screen to share: Select Window or Screen" menu UI.

Comment 1

[guest271314]

<video> should be set as an AWindow or Screen to share: Select Window or Screen at the display capture menu UI. The Screen Capture specification does not prohibit listing of the HTML <video> element as an application.

Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=994953

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[guest271314]

Component should be WebRTC: Audio/Video https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=WebRTC%3A%20Audio%2FVideo

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

What would the use case be? FWIW we have no current plans for such a feature.

Comment 5

[guest271314]

When Picture-In-Picture is used on a <video> element is already is possible to capture the PIP window using getDisplayMedia().

The use case when filed this bug was to capture variable width and height video playback.

Technically Web Media Player that browsers use to playback media is an "application".

Comment 6

[guest271314]

The use case is essentially to

• overcome MediaRecorder stopping recording when <video> src is changed in lieu of replaceTrack() and/or replaceStream() being specified and implemented for MediaRecorder (does not matter if/when src is changed because we are capturing the application window itself, not the current URL set at src, where if src is changed or no src at all the application window can still be recorded)
• "seamless" recording of multiple audio and video (potentially containing variable width and height frames)
• treat <video> and <audio> as the application windows they actually are

Comment 7

[guest271314]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #4)

What would the use case be? FWIW we have no current plans for such a feature.

Basically these two approaches should be possible without using window.open() or picture-in-picture or requestFullScreen(); workarounds for areas not covered or limited by MediaRecorder, getDisplayMedia(), MediaStream specifications, for the use case of recording a <video> without having to code for src changing (where MediaRecorder stops), proof-of-concepts for this approach (getDisplayMedia())

• https://github.com/guest271314/MediaFragmentRecorder/blob/getdisplaymedia-webaudio-windowopen/MediaFragmentRecorder.html

• https://github.com/guest271314/MediaFragmentRecorder/blob/getdisplaymedia-pictureinpicture/MediaFragmentRecorder.html

• https://github.com/guest271314/MediaFragmentRecorder/tree/getdisplaymedia-webaudio

Hopefully the above list items clears needsinfo for why request the feature of capturing HTML <video> element as an "application" or window within the purview of getDisplayMedia().