Re: Constraints structure and Capabilities API

Cullen Jennings wrote:
> Rich, not really sure what you are getting at here - I agree with your points but it seems like the proposed API would do everything you want.
>
>>
>>> What if the app wants to process the data (image recognition, etc), but
>>> to reduce processing load (or reduce low-light noise) wants a lower
>>> resolution or lower framerate or both?
>> This was one of the points in my previous email. I think there is a case to limit the sheer amount of pixel data you get back in some cases. Specifically I'm thinking about real-time analysis use cases but I see that as one flag hint rather than a set of min/max properties.
>>
>
> Lets say due to IP, you only wanted no more than 5 mpix / second. You would set just one constraint.
>
> 0:{video-max-pixelrate:5.0, mandatory:true}
>
> That's it and the rest would just happen. Dan seems to have exactly what you wanted.

I was suggesting that this was perhaps the only absolute requirement for 
the API - and only because of current hardware constraints otherwise 
this too would not be necessary. All of the other options should just be 
handled implicitly when a user agent provides a MediaStream by 
defaulting to a reasonable set of media characteristics that enable 99% 
of the local use cases without developers needing to deal with the extra 
complexity introduced by the Capabilities API. Then that MediaStream 
object would be free to adopt different characteristics, again 
implicitly, when we come to stream or record it rather than requiring 
developers to tweak those settings manually. That may be a nice feature 
to have in version 2 but doesn't seem like something entirely necessary 
in a first implementation.

- Rich

Received on Friday, 2 March 2012 13:38:40 UTC