Re: Spec question: Using settings dictionaries instead of MediaConstraints

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. 

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 Thursday, 28 June 2012 17:59:42 UTC