Consider using Promises for capturing from HTMLMediaElement

[yell0wd0g]

Spec says [here](https://w3c.github.io/mediacapture-fromelement/#dom-htmlmediaelement-capturestream()):

Unless and until there is a track of given type that is selected or enabled, no MediaStreamTrack of that type is present in the captured stream. In particular, if the media element does not have a source assigned, then the captured MediaStream has no tracks. Consequently, a media element with a ready state of HAVE_NOTHING produces no captured MediaStreamTrack instances. Once metadata is available and the selected or enabled tracks are determined, new captured MediaStreamTrack instances are created and added to the MediaStream.

Which essentially dumps onto the WebApp to monitor the MediaStream to check if and when there is actual content in the <video>/<audio>. Instead, I propose changing captureStream() to return a Promise that gets fulfilled when there is active rendering on the Media Element, and gets rejected e.g. due to cross-origin checks (note that currently such a condition is not flagged in any way except for just having no data in the Tracks, i.e.

The contents of the track might become inaccessible to the current origin due to cross-origin protections. For instance, content that is rendered from an HTTP URL can be subject to a redirect on a request for partial content, or the enabled or selected tracks can change to include cross-origin content.

)

[martinthomson]

We already have the issue that tracks can have nothing in them periodically in WebRTC. Being consistent with that might be best.

[Pehrsons]

An issue with a promise approach is that what is rendered by the media element may change over time (e.g., it may have no tracks due to a cross-origin resource, but later play a src on the same origin); whereas a promise is a one-off.

Also the application already knows whether or not it uses cross-origin resources, so using a promise goes against principles we have called out before (like no "ended" event on track.stop()).

To understand the full state of the rendered media one has to monitor the tracks of the MediaStream IMHO.

[yell0wd0g]

My proposal only includes creation, i.e.: Promise<void> captureStream() will be resolved with a captured MediaStream that from that point onwards behaves normally including adding/removing tracks being signalled via its events.