W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Spec question: Using settings dictionaries instead of MediaConstraints

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 29 Jun 2012 07:08:12 +0200
Message-ID: <4FED383C.9040904@ericsson.com>
To: public-webrtc@w3.org
On 06/28/2012 07:00 PM, Cullen Jennings wrote:
>
> On Jun 21, 2012, at 18:37 , Justin Uberti wrote:
>
>>
>>
>> On Thu, Jun 21, 2012 at 6:42 PM, Cullen Jennings <fluffy@iii.ca>
>> wrote:
>>
>> On Jun 20, 2012, at 9:21 , Harald Alvestrand wrote:
>>
>>> On 06/19/2012 03:45 PM, Justin Uberti wrote:
>>>>
>>>>
>>>> On Tue, Jun 19, 2012 at 8:57 AM, Stefan Hakansson LK
>>>> <stefan.lk.hakansson@ericsson.com>wrote: On 06/19/2012 08:30
>>>> AM, Randell Jesup wrote: On 6/18/2012 3:22 PM, Justin Uberti
>>>> wrote:
>>>>
>>>>
>>>> On Mon, Jun 18, 2012 at 2:57 PM, Cullen Jennings (fluffy)
>>>> <fluffy@cisco.com<mailto:fluffy@cisco.com>>  wrote:
>>>>
>>>>
>>>> This seems like good proposal, one comment on a small detail.
>>>>
>>>> On Jun 15, 2012, at 1:28 PM, Justin Uberti wrote:
>>>>
>>>>> SessionDescriptionOptions.IncludeAudio = true/false //
>>>>> forces
>>>> m=audio line to be included
>>>>> SessionDescriptionOptions.IncludeVideo = true/false //
>>>>> forces
>>>> m=video line to be included
>>>>> SessionDescriptionOptions.UseVoiceActivityDetection =
>>>>> true/false
>>>> // includes CN codecs if true
>>>>
>>>> I think these three should be constraints, not settings because
>>>> a given browser may not support any of them.
>>>>
>>>>
>>>> Practically speaking, what does that mean for applications?
>>>>
>>>> I can conceive of a browser implementing audio but not video.
>>>> And a gateway or other stand-alone WebRTC box/functionality
>>>> might include JS and these JS apis for ease of programming (and
>>>> might be audio-only). (I'd try to avoid it in production,
>>>> probably, but even that might not be needed with modern JS JIT
>>>> speed so long as it didn't have to tear down and restart all
>>>> the time.)
>>>>
>>>> CN codecs: I dislike them anyways.  :-)  An implementation
>>>> definitely could avoid including those.
>>>>
>>>> Many codecs have built in CN modes. I guess for those it is
>>>> more a question of being able to switch off the VAD.
>>
>>
>> I think we need to focus on VAD not CN. Note all the use cases
>> erased are about VAD not CN. Note the text in section 5.1 is only
>> about VAD and says
>>
>> VoiceActivityDetection This is a enum type constraint that can take
>> the values "true" and "false". The default is a non mandatory
>> "true".
>>
>> Many codecs and system are capable of detecting "silence" and
>> changing there behavior in this case by doing things such as not
>> transmitting any media. In many cases, such as when dealing with
>> sounds other than spoken voice or emergency calling, it is
>> desirable to be able to turn off this behavior. This constraints
>> allows the application to provide information about if it wishes
>> this type of processing enable or disabled.
>>
>> I understand what you are saying, but other than omitting "CN" from
>> the list of codecs, what other effect do you expect this constraint
>> to have on the generated SDP?
>>
>
> I don't think it will change the SDP at all in most case - it will
> change the behavior of the local audio encoder in the media stack so
> that even when it is "quiet", the encoder keeps sending audio
> packets.
>
> This is useful when doing something like music where you don't want
> to stop sending audio when things get quiet. It is also required for
> E911 calls - note I am not saying we need to take into account all
> E911 requirements - I'm just saying this functionality has saved
> lives. I imagine some games would want it. For "phone call" like
> applications, typically you don't want to enable it because you want
> to try and mask background noise from being sent. In audio
> engineering terms, one might think of this as causing the "gate"
> setting to be set at a large negative number instead of whatever it
> is typically set at.
>
> I'm not arguing that all implementation are required to support this
> - I just want a common API for it for the implementation that do
> support it.

This is a MUST in the use-case/requirement document:

"The Web API MUST provide means for the web
                    application indicate the type of audio signal
                    (speech, audio)for audio stream(s)/stream
                    component(s)."

>
> The functionality is clearly associated with an audio Track but it
> still seems reasonable to set it in a create offer or answer which
> would mean that it applied to all tracks is the Peer Connection. (I
> can be convinced I am nuts on the this last point but that was how I
> was thinking about it)
>
>
>
>
>
Received on Friday, 29 June 2012 05:08:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC