Re: CHANGE: Provide JSONHints interface for media streams

On 10/06/2011 03:18 PM, Timothy B. Terriberry wrote:
>> This sounds like a good idea. But would not the natural time to add
>> "hints" be at getUserMedia time?
>
> I think the answer is "yes", but there's already the "JS Object" that
> Anant was proposing in his change. Though I think the idea there was to
> tell the browser which type of media (audio, video, or both) you are
> requesting, there's no reason browsers couldn't interpret more
> properties there later on.

Sounds good.

>
>> My reasoning being that the "hints" (as you say below) are in 99.9% of
>> the time set once and never changed, and can in addition have an effect
>> already earlier in the chain (before the codec). E.g. if a hint is "fast
>
> Also, on the converse side, one might want to specify hints when sending
> a MediaStream that did not originate with getUserMedia() (e.g., one that
> came from an<audio>  tag, etc.). That is, in fact, exactly where you
> would want to specify audioApplication: General instead of
> audioApplication: VOIP. The only part of the audio chain that I can
> think of that you might want to disable on the getUserMedia() side is
> the AEC, and I'm not sure exposing that knob is a good idea (it may be
> okay if you know the user is using headphones, but it's the browser, not
> the JS, that has the best chance of figuring that out).

I did not think of the cases when the source is something else, like a 
local file. For these cases I agree that the time to hint would be at 
addStream

>
>> moving content" the camera might be set up to record with a higher frame
>> rate - the effect would be visible in a view finder even if the
>> MediaStream is never transported off the device using a PeerConnection.
>
> I'm not sure if "hints" are the best approach to specifying things like
> framerate. An API to query capabilities and make specific requests (with
> feedback to tell you didn't get what you asked for) may be better (and
> would certainly make folks like Kaufman happy), but one step at a time.
> Also, keep in mind that many consumer-grade webcams will simply lie
> about things like this (they tell you you're getting 30 fps, but the
> frame actually only changes maybe 4 times a second).

:)

I was not really looking for specifying framerate, I am more fond of the 
"hints" concept, letting the browser (and the rest of the system) make 
its best based on the hints.

But I fully agree to that we should do this one step at a time, basic 
functionality first and then extend.

>

Received on Thursday, 6 October 2011 13:42:32 UTC