- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 2 Mar 2012 15:01:10 +0100
- To: public-webrtc@w3.org
On 03/02/2012 02:37 PM, Rich Tibbett wrote:
> 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, at the Telco this week it was said that the browser defaults to
(i.e. what you get if the app does not supply any "constraints") is
really important. Also an app that does not use "constraints" should get
good quality audio and video (how to define "good quality" is another
story).
>
> - Rich
>
Received on Friday, 2 March 2012 14:01:38 UTC