- From: Arun Ranganathan <arun@mozilla.com>
- Date: Thu, 29 Aug 2013 17:01:00 -0600
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: public-webapps@w3.org, public-media-capture@w3.org
- Message-Id: <23554518-883B-4049-9C7D-6A33D78DB5DC@mozilla.com>
On Aug 28, 2013, at 9:48 AM, Dominique Hazael-Massieux wrote: > Hi WebApps WG, > > The Media Capture Task Force (responsible for specs that deal with > MediaStream objects [1]) has been considering whether one should be able > to assign a MediaStream to <video> and <audio> elements via an URL > obtained via createObjectURL or not, and is seeking feedback on the > question. > > More precisely: > A. we define a new srcObject attribute on HTMLMediaElement objects that > can take directly a MediaStream object and make it playable > video.srcObject = mediastream; > B. the spec also supports assigning a MediaStream via the src attribute, > via an URL obtained through createObjectURL: > video.src = URL.createObjectURL(mediastream); > > While there are ongoing discussions on how to spec B properly [2] (which > will require coordination with the WebApps Working Group), we are first > and foremost wondering if that option is needed at all. > > We are thus looking for input on the use cases for createObjectURL as > used for the File API, and whether these use cases would also apply to > our MediaStream case. In general, is there a need for any object > readable by media elements to support an URL-based approach for > consistency with the rest of the platform? The fact that URL.createObjectURL exists at all is hitched to the ongoing use of strings as URLs in places like Image ("img src=") and CSS. This also created the discussion about autoRevoke (namely the automatic revocation of these references), for which we added URL.createFor. As it stands, developers should bear the onus of calling URL.revokeObjectURL coupled to URL.createObjectURL, which may be a tall request. MediaStream may not be as ubiquitous as Blob, and you may be able to avoid URL strings altogether. If that's a fair assumption, option A seems like a good plan. If you go the option B route, then you'll have to also think about revocation and URL.createFor, since you'll have the same problem. On balance, I favor Option A, unless you make the case for strings :) If you choose Option B, I'm happy to work with your WG to make sure File API has the right hook for MediaStream objects, per https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594 -- A* -- A*
Received on Thursday, 29 August 2013 23:01:39 UTC