W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2013

Re: Proposal for output device selection

From: Sam Dutton <dutton@google.com>
Date: Tue, 13 Aug 2013 11:55:02 +0100
Message-ID: <CAACxJ5q3dVqFdeHVitd5Y9UosTHk3kutdFpvw-Dh58sXUBzJaQ@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: (wrong string) ›š›˜›˜š) <tommyw@google.com>, Tommi Gunnarsson <tommi@google.com>
This sounds really useful.

As suggested, output device selection would be handy for video as well as

For example:
- video stream from one WebRTC call participant directed to one display,
another to another
- screencast of an app demo to one display, screencast of a presentation to
- output video from CCTV (or cameras at an event) to multiple displays

Would there ever be a situation where it might be desirable to direct
output of a single video or audio element to multiple devices, i.e. have
more than sinkId for a single audio or video element? For example: direct
output from one input stream to displays 1 and 2, and from another input to
displays 3 and 4.

Also (pedantic): is there a rationale for choosing properties (like sinkId
here) over get/set methods such as MediaStream getVideoTracks()?


On 13 August 2013 09:09, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Le mardi 13 aot 2013  06:50 +0000, Stefan Hkansson LK a crit :
> > But I would really like to get comments from people involved in the
> > html5 and media elements work.
> This also has strong links with the Audio API model; there seems to have
> been already some related discussion there:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21345
> (this need was actually one of the topics we highlighted to the Audio WG
> back in TPAC 2011:
> http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0056.html )
> So +1 in general for addressing that requirement, but also big +1 in
> coordinating with both the HTML Working Group Media Task Force and the
> Audio Working Group on this.
> Dom
Received on Tuesday, 13 August 2013 10:55:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC