W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > February 2017

[mediacapture-fromelement] Consider using Promises for capturing from HTMLMediaElement

From: Miguel Casas-Sanchez via GitHub <sysbot+gh@w3.org>
Date: Fri, 10 Feb 2017 19:50:16 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issues.opened-206890257-1486756214-sysbot+gh@w3.org>
miguelao has just created a new issue for 
https://github.com/w3c/mediacapture-fromelement:

== Consider using Promises for capturing from HTMLMediaElement ==
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.

)

Please view or discuss this issue at 
https://github.com/w3c/mediacapture-fromelement/issues/58 using your 
GitHub account
Received on Friday, 10 February 2017 19:50:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:31 UTC