Re: Proposal for output device selection

On Tue, Aug 13, 2013 at 3:55 AM, Sam Dutton <dutton@google.com> wrote:

> This sounds really useful.
>
> As suggested, output device selection would be handy for video as well as
> audio.
>
> 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 another
> - 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.
>

Unlike audio, video already has a robust mechanism for controlling output,
i.e. the browser's layout engine + the computer's windowing system. While
there might be a place for a mechanism to enumerate 'desktops', and to
place a browser window into different desktops, the idea of having a video
tag render to a specific device doesn't seem like a great fit.

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

I didn't see much precedent for setter functions in the HTML5 DOM; for
example, you set the source of a HTMLMediaElement via element.src = foo.

>
> Sam
>
>
> On 13 August 2013 09:09, Dominique Hazael-Massieux <dom@w3.org> wrote:
>
>> Le mardi 13 août 2013 à 06:50 +0000, Stefan Håkansson 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
>>
>>
>>
>>
>