- From: Justin Uberti <juberti@google.com>
- Date: Fri, 22 Jun 2012 14:50:26 -0400
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
- Message-ID: <CAOJ7v-1JoRcFPjyGbgwjsBQeXk-_vL-=aeUK+gzZCM4RZP8Nmw@mail.gmail.com>
On Fri, Jun 22, 2012 at 1:03 PM, Harald Alvestrand <harald@alvestrand.no>wrote: > On 06/22/2012 03:37 AM, 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? > > > It might not even have that effect. The SDP would reasonably announce CN > as long as the browser was able to receive it, because the other partner > might want to use CN, or another track that was added later might set VAD > to true even if the first track had it false. > > The important setting would be that the codec is configured not to choose > to generate silence on no-voice-activity; this is a pure sender-side > decision. > > That means this constraint needs to be on a Stream or Track, not createOffer. If it doesn't change the generated SDP, it can't go on createOffer.
Received on Friday, 22 June 2012 18:51:16 UTC