Re: WebRTC Web APIs for On-board Multimedia Devices Handling and Control

Adam,
The latest draft for Media Capture and Streams W3C Editor's Draft 05
November 2013 contains a new section addressing parts of my requested
detailed below in section - *8.Enumerating Local Media Devices*. The prior
drafts did not have/specify this section nor the content related to these
capabilities/APIs.

I'd like to thank and appreciate you and your team for taking my request
and incorporating those into the specification.

I think some of what I'd requested and written down - like events related
to the change in device availability etc. capabilities still seem to be not
specified and I believe such capabilities will be necessary for an
enjoyable end-user experience which will drive the growth of webRTC and
make web more useful than what it is today.

-- 
Regards,
Venkateswar Reddy Melachervu
"...dare to dream, care to win..."
www.linkedin.com/in/vmelachervu

Hi

We have two documents that specify, or is the place to specify, what you
want.

Media Capture and Streamshttp://dev.w3.org/2011/webrtc/editor/getusermedia.html
This document specifies how the script can get access to local media
input devices. It's also the place to read about how you can control
these devices (look for constraints).

WebRTC 1.0: Real-time Communication Between
Browsershttp://dev.w3.org/2011/webrtc/editor/webrtc.html
This document specifies the API which you use to send and receive
streams from other browsers (or misc WebRTC peers).

/Adam

On 2013-07-08 04:26, Venkateswar Reddy Melachervu wrote:
> Team WebRTC,
> First of all let me congratulate you for the awesome work you have done
> and are doing to liberate the multimedia control from the clutches of
> native OS' walled garden while as you read this mail many civil
> societies wage war against the walled freedom across the globe.
>
> I am just beginning to get into the innards of the WebRTC and request
> your patience for what may seem like novice queries.
>
> The over-arching query I've is related the framework for web APIs for
> the control/handling of multimedia devices for audio, video and screen
> share sessions from within a browser-side web app (HTML, Javascript).
> More specifically :
>   - Getting list of available devices and selecting a device for audio,
> video - mic, speaker, camera - session from the OS available devices
>   - Getting and setting device properties like device name, device id,
> sampling rate, echo cancellation etc for audio, video etc. - mic,
> speaker, camera etc.
>   - Getting and setting OS default device for speaker, mic, camera
>   - Muting/un-muting a device/stream
>   - Getting events for:
>        - When a device - mic, speaker, camera becomes
> disabled/unavailable/plugged out
>        - When a device - mic, speaker, camera becomes
> enabled/available/plugged-in
>        - When a device property like sampling rate etc. change - mic,
> speaker, camera
>        - When a default device selection changes - mic, speaker, camera
>
> My question is : are there web APIs (IETF) for WebRTC for the above
> purposes in defined/available today for a web app developer like us who
> is developing a web app (html, javascript only) that cuts across audio,
> video and screen shares - in browsers (desktop and android)? My initial
> searching and google searching did not yield the answer I was looking
> for either across the IETF drafts or web.
>
> These are non-negotiable controls a multimedia web app needs to have to
> offer a seamless, acceptable, WORAB - write once, run on any browser,
> multimedia experience to the end users and for the success of web - more
> so for the success of WebRTC itself, in my view. If not-addressed by
> IETF, browser makers will eventually be forced to introduce proprietary
> APIs - nullifying the global goal of making the web work for all.
>
> Let's liberate the multimedia control from the clutches of OS walled
> garden for the success of web on this very month a great nation attained
> freedom and set an example to the world of freedom and free and open
> markets.
>