Re: [whatwg] Media sink device selection on audio/video
Thanks Ian. I pinged public-media-capture about this and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245 is now tracking making that spec better specified. On Wed, Apr 2, 2014 at 10:52 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
Ian, On Fri, Feb 7, 2014 at 4:55 PM, Ian Hickson i...@hixie.ch wrote: Can you let us know when there's a URL that will permanently hold the latest (including day-to-day updates) spec? Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Cheers, -a
Re: [whatwg] Media sink device selection on audio/video
Ian, The link you're looking at is currently being used to focus the WG's attention on the Constrainable business, which is why everything else has disappeared. This is temporary :) See http://lists.w3.org/Archives/Public/public-webrtc/2014Feb/.html for the haps, and the previous editor's draft ( http://dev.w3.org/2011/webrtc/editor/archives/20131225/getusermedia.html) for the pieces of the spec discussed in this thread here. Cheers, -a On Fri, Feb 7, 2014 at 2:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 18 Dec 2013, Ami Fischman wrote: On Wed, Dec 18, 2013 at 8:38 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 17 Dec 2013, Ami Fischman wrote: Recently https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263 Navigator acquired the ability to enumerate media output devices (in addition to input devices): http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices What's the privacy story for this API? I don't follow public-media-capture but the spec above says: The method must only return information that the script is authorized to access (TODO expand authorized). That should probably be resolved before we start integrating other specs with the API, since without a solid privacy story, the API might change radically. In fact, looking at the spec again today, I can't find anything about enumerating anything. (Indeed, the word enumerating doesn't appear in that spec.) Am I missing something? There doesn't seem to be a table of contents either... Anyone know the status of that spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Sun, Jan 12, 2014 at 8:47 PM, Philip Jägenstedt phil...@opera.comwrote: [...] Do you mean to make this per-origin as well? (It will require storing that information per-origin forever, or until some invisible timeout.) That seems about as restrictive as one could make it, but is the API going to actually be useful in this state? Sure, why not? Canonical use-case: webrtc-using video-chat webapp allows the user to select between speakers, wired headset, or bluetooth headset for its audio output; the webapp already has gUM permission so now it can use getMediaDevices() to enumerate output sinks and use the proposal here to route the remote audio feed to the desired device. Cheers, -a
Re: [whatwg] Media sink device selection on audio/video
Hmm; I wasn't thinking in terms of per-device, only per-origin and per-browser/machine. Seems like a conversation for public-media-capture? On Mon, Jan 13, 2014 at 3:30 PM, Philip Jägenstedt phil...@opera.comwrote: On Tue, Jan 14, 2014 at 5:51 AM, Ami Fischman fisch...@chromium.org wrote: On Sun, Jan 12, 2014 at 8:47 PM, Philip Jägenstedt phil...@opera.com wrote: [...] Do you mean to make this per-origin as well? (It will require storing that information per-origin forever, or until some invisible timeout.) That seems about as restrictive as one could make it, but is the API going to actually be useful in this state? Sure, why not? Canonical use-case: webrtc-using video-chat webapp allows the user to select between speakers, wired headset, or bluetooth headset for its audio output; the webapp already has gUM permission so now it can use getMediaDevices() to enumerate output sinks and use the proposal here to route the remote audio feed to the desired device. OK, so a site that has been given access to any device using getUserMedia can then enumerate all devices using getMediaDevices? I interpreted devices to which the user has already granted access through getUserMedia in the most restrictive (per-origin, per-device) way possible... Philip
[whatwg] Media sink device selection on audio/video
Recently https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263 Navigator
acquired the ability to enumerate media output devices (in addition to
input devices):
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices
It would be nice to allow media elements to direct their output to such an
output device.
The primary use-case is to allow app UI/script to select which audio output
device should play the audio track of a video or audio tag (wired
speakers, bluetooth headset, etc.).
A simple impl (mentioned only in case the above is too vague and would
benefit from concreteness; I have no attachment to this particular version)
would look like: extend html media elements with new
{audio,video}OutputDeviceId attributes which:
- when read provides the last-set value, or if never set, the UA's idea of
a default device (probably influenced by the OS's idea of a default device)
- when set directs the relevant type of output (audio/video) from the
element to the device in question
(specified as deviceId)
(note that the Media Capture spec only specifies an audioOut kind, not a
videoOut kind, so it probably makes sense to only offer an
audioOutputDeviceId attribute for now, but naming it outputDeviceId
(omitting audio) might be a regrettable move in the future if/when Media
Capture adds videoOut to the kind enum).
Cheers,
-a
[whatwg] Reporting mid-stream resolution change on video
Today the video tag exposes video{Width,Height} attributes that allow the
page to discover the resolution of the playing media once metadataloaded
has fired. However there is no way for the page to find out that the media
resolution has changed mid-stream (short of polling the tag constantly,
which is obviously unappealing).
Examples where mid-stream resolution change can happen include:
- WebRTC up/down-scaling a video stream at the source to adhere to
available bandwidth or other requirements
- MSE shifting between quality levels of source material
- Static/VOD/classic video files that change resolution mid-stream b/c of
different source material being concatenated together.
One way to enable this would be to add a metadatachange event to the list
of media elements events (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-definitions
).
(this has come up recently in a public-webrtc
threadhttp://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0040.html,
and previously in private discussions)
Cheers,
-a
Re: [whatwg] Reporting mid-stream resolution change on video
Thanks Ian. My reading of
http://html5.org/tools/web-apps-tracker?from=8346to=8347 is that a simple
video that never changes size will never see the new resize event. Is that
intentional?
(I ask b/c e.g. durationchange _is_ fired right before metadataloaded; I'd
expect resize durationchange to act similarly in terms of whether they
fire on initial load)
Related, it's strange to me that
At this point,
resizehttp://www.whatwg.org/specs/web-apps/current-work/#event-media-resize
events
can start firing.
but readyState is still HAVE_NOTHING, which is precluded by
http://www.whatwg.org/specs/web-apps/current-work/#event-media-resize's
Preconditions.
Would it make sense to make resize fire right before metadataloaded fires
and remove its Preconditions (both mimicking durationchange)?
Cheers,
-a
On Thu, Dec 12, 2013 at 12:04 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 12 Dec 2013, Ami Fischman wrote:
Today the video tag exposes video{Width,Height} attributes that allow
the page to discover the resolution of the playing media once
metadataloaded has fired. However there is no way for the page to find
out that the media resolution has changed mid-stream (short of polling
the tag constantly, which is obviously unappealing).
Examples where mid-stream resolution change can happen include:
- WebRTC up/down-scaling a video stream at the source to adhere to
available bandwidth or other requirements
- MSE shifting between quality levels of source material
- Static/VOD/classic video files that change resolution mid-stream b/c of
different source material being concatenated together.
One way to enable this would be to add a metadatachange event to the
list of media elements events (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-definitions
).
(this has come up recently in a public-webrtc
thread
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0040.html,
and previously in private discussions)
Seems reasonable. Done. (I used the 'resize' event since it is well
established as the appropriate event to use when dimensions change.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reporting mid-stream resolution change on video
On Thu, Dec 12, 2013 at 2:56 PM, Ian Hickson i...@hixie.ch wrote: I suppose we could fire resize on initial load as well. I guess it depends on what code that uses this looks like. Is the initial size change the same kind of code as resizing, or is it different code? (e.g. will one set up elements to frame the video while the other just changes their size?) Yes, I think that the first size event and subsequent ones are similar enough that the initial size info should be fired when metadataloaded fires. Example use-cases: - a chat service wants to display an HD emblem on video feeds above some threshold (and removed it if/when they fall below the threshold). You want to show/hide the emblem from the first point at which you have size information, and each time that information changes. - an on-screen display (OSD) for feed resolution; needs to be updated on resize as well as initial size information. In fact I am failing to think of examples where only not-first resize information would be needed. Cheers, -a
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 9:46 AM, Francis Boumphrey boumphre...@gmail.comwrote: In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. The spec does specify this, and chrome fails to follow the spec. See http://webk.it/75154 for details. Cheers, -a
