RE: Constraints and Capabilities API for getUserMedia: more detailed proposal

>-----Original Message-----
>From: Rich Tibbett [mailto:richt@opera.com]
>
>Dan Burnett wrote:
>> Group,
>>
>> Here is the proposal for Constraints and Capabilities for the
>getUserMedia draft.

I definitely think we're on to something good here. Like many others that have 
commented, I think there's a concern that this infrastructure makes the API too 
complicated. At the same time if offers a great deal of control for some use 
cases that have specific constraints/requirements, which is exactly the purpose 
of the proposal.

With this general framework in mind, it should be easier to simplify this for the
common use cases (while keeping the options open for more complicated constraint
management).


>
>> Example:
>>
>> {camera001:{
>>    video-min-width:  800,
>>    video-max-width:  1024,
>>    video-min-height:  600,
>>    video-max-height:  768,
>>    video-min-aspectratio:  1.333333333333,
>>    video-max-aspectratio:  1.333333333333,
>>    video-min-framerate:  24,
>>    video-max-framerate:  60,
>>    video-min-pixelrate:  15,
>>    video-max-pixelrate:  47,
>>    video-min-timebetweenkeyframes;  20,
>>    video-max-timebetweenkeyframes:  40,
>>    video-min-bandwidth:  1.5,
>>    video-max-bandwidth:  3.5},
>> camera002:{
>>    video-min-width:  1600,
>>    video-max-width:  1920,
>>    video-min-height:  1080,
>>    video-max-height:  1200,
>>    video-min-aspectratio:  1.33333333333,
>>    video-max-aspectratio:  1.77777777777,
>>    video-min-framerate:  24,
>>    video-max-framerate:  120,
>>    video-min-pixelrate:  57.6,
>>    video-max-pixelrate:  248,
>>    video-min-timebetweenkeyframes;  20,
>>    video-max-timebetweenkeyframes:  40,
>>    video-min-bandwidth:  8,
>>    video-max-bandwidth:  29.4},
>> audio001:{
>>    audio-min-bandwidth:  1.4,
>>    audio-max-bandwidth:  128,
>>    audio-min-mos:  2,
>>    audio-max-mos:  5,
>>    audio-min-codinglatency:  10,
>>    audio-max-codinglatency:  50,
>>    audio-min-samplingrate:  8000,
>>    audio-max-samplingrate:  48000}}
>>
>
>As mentioned on the conf call, if this proposal is targeted at
>getUserMedia, I'd like to see how it maps to some of this group's
>original use cases and requirements - especially those documented in [1].
>
>I do think it makes sense to apply characteristics at recording or
>streaming time but I'm unsure as to why I would need to, as a web
>developer, have to go and look up these parameters in a registry and
>then configure a stream object to this level to get some local playback
>going (it's very IANA and web apis typically don't require a manual, a
>steep learning curve on the internals of codecs or registries).


I think we should definitely consider which constraints make sense at 
each stage of the MediaStream's use cases:
1. initial request
2. re-configuration of the Media Stream (if allowed)
3. local capture/recording of the media stream
4. broadcasting configuration (for sending/receiving)

For #1, we need to understand the nature of what is being returned by
getUserMedia (as noted by Rich below). If the MediaStream is pre-configured
by the constraints before being returned, then what happens on subsequent
request to getUserMedia with different constraints that change the 
configuration? Can it be a singleton instance in that case? If so, what
happens to the previously provided MediaStream? 

For example, say I request a MediaStream with a mandatory "video-min-width": 800, and
I get a MediaStream that meets that constraint. Then, I call getUserMedia
again, but I place a mandatory "video-max-width": 700 constraint on the stream.
Assuming that it is possible for the second constraint to be granted, and that the
device only has one physical camera, should it grant the second request?
If so, what is the effect on the first MediaStream?

These questions still exist without using a constraints API, but are a 
little simpler to answer, since the "constraints" were simple (e.g.,
"please give me 'audio' and/or 'video'" -- the constraints only 
represented devices that could be assumed to be singletons).

-Travis

>- Rich
>
>[1] http://www.w3.org/TR/capture-scenarios/
>[2] http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0047.html
>

Received on Tuesday, 20 March 2012 18:18:32 UTC