- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 31 Jan 2013 15:22:05 +0100
- To: public-webrtc@w3.org
- Message-ID: <510A7E0D.9050608@alvestrand.no>
On 01/31/2013 08:21 AM, Justin Uberti wrote: > This feels like we are heading down the path of creating a low-level > API, but using constraints, which seems like the wrong control surface. > > Wouldn't it be better to provide accessors on SessionDescription to > allow these properties to be set directly? This would allow any > configuration to be set without having to a) add a constraint for each > feature and b) perform any SDP munging. > My thinking for some of these is that they're backwards compatibility hacks that are only needed when talking to legacy devices where standard SDP negotiation won't do the Right Thing. On some others (like bandwidth), my thinking is that they are constructs that need to be applied at an appropriate level, which will often not be the SDP level - and the application should not have to think about the details. For instance, setting bandwidth on a video stream will affect the behaviour of both the codec and the congestion control apparatus - setting bandwidth on a whole PeerConnection will also affect the codec and congestion control, but allows more tradeoffs as it trickles down the stack. > > > > > > On Mon, Jan 28, 2013 at 6:29 AM, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > On 2013-01-28 15:11, Cullen Jennings (fluffy) wrote: > > > Resend of message to list with no attachment. > > > Begin forwarded message: > > Hi Cullen > > Your message hasn't made it to the list, because its size > (due to the > attachment) is larger than what our list accepts; you > could post the > attachment somewhere else (e.g. on the group wiki, or as > an attachment > to a message to www-archive@w3.org > <mailto:www-archive@w3.org>) and then re-send your message > with a > pointer to the on-line version of the file? > > Thanks, > > Dom > > Le dimanche 27 janvier 2013 à 23:11 +0000, Cullen Jennings > (fluffy) a > écrit : > > In several meetings we have discussed that we need to > do things like allow the JS to disable the bundle > option but that never got that in the API draft. > > We have also discussed that for common things that > people want to do to manipulate SDP, it's better to > privde a simple programatic way of doing that than > making them parse and recreate SDP. I'd like to > propose a simple set of constraints to add to the > PeerConnection to do the things people have identified > in the past as desirable. Note that 99% of JS > applications would probably never set any of these. > I've considered the code in FF & Chrome a bit and they > seem easy to implement. > > > > UseRtpMUX > > This is an enum type constraint that can take the > values "true", "false". The > default is a non mandatory "true". > > This indicates that a the RTP packets should all be > multiplexed on the same > UDP port. > > UseRtcpMUX > > This is an enum type constraint that can take the > values "true", "false". The > default is a non mandatory "true". > > This indicates that a the RTCP and RTP packets should > all be multiplexed on > the same UDP port. > > UseAVPF > > This is an enum type constraint that can take the > values "true", "false". The > default is a non mandatory "true". > > This indicates that RTCP Feedback Capability Attribute > mechanisms as specified > in RFC 4585 should be used. > > UseRtpExtensions > > This is an enum type constraint that can take the > values "true", "false". The > default is a non mandatory "true". > > This indicates that RTP header extensions can be used. > > > For the above, it is not clear where/when they can be applied. It > could be: > a. At PeerConnection creation (meaning that all offers/answers > created would follow those constraints) > b. At createOffer/Answer - but then what should happen e.g. if you > have a session going that is all multiplexed, but then you create > a new Offer with constraints saying "do not multiplex"? Should the > complete session re-negotiate (to not use multiplexing), or should > just new streams/tracks follow the new constraints? > c. associated with a certain MediaStream or MediaStreamTrack. > Would mean that some streams/tracks could use multiplexing, some not. > > To me a. seems the clearest. > > > > JavascriptMediaAccess > > This is an enum type constraint that can take the > values "true", "false". The > default is a mandatory "false". > > This indicates that JavaScript can access the media > content such as audio or > video. The reason for defaulting to false is to make > it easier to detect an > applications that changes it to true. Browsers MUST > support this constraint > and MUST implement the "false" option as this is > important for security. > > > Is this not more relevant for the getUserMedia document, and less > for webrtc? > > > > AudioFrameSize > > This is an max type constraint. The default is a non > mandatory "20". > > This indicates the desired size for RTP audio frames > in mili seconds. If you > think you need to adjust this, it will probably reduce > your interoperability > with other systems. > > AudioEncodingComplexity > > This is an integer type constraint that can take the > values 1 to 10. The > default is a non mandatory "5". Open Issue: IANA > Constraints registry does not > seem to work for this. > > This indicates the relative amount of CPU that should > be used by the audio > encoder. 10 means more CPU. 1 means less. What this > does will be dependent on > the implementations and the codec chosen. If you feel > you need to adjust this, > it probably won't do what you want. > > VideoEncodingComplexity > > This is an integer type constraint that can take the > values 1 to 10. The > default is a non mandatory "5". Open Issue: IANA > Constraints registry does not > seem to work for this. > > This indicates the relative amount of CPU that should > be used by the video > encoder. 10 means more CPU. 1 means less. What this > does will be dependent on > the implementations and the codec chosen. If you feel > you need to adjust this, > it might make some difference. > > ConstantBitRateAudio > > This is an enum type constraint that can take the > values "true", "false". The > default is a mandatory "true". > > This indicates if the audio and codecs should allow > variable or constant bit > rate audio encoding. Due to possible security concerns > with variable bit rate > audio, this defaults to using constant bit rate. > Browsers MUST implement this > constraints and MUST support a constant bitrate option > as this is important > for security. > > MaxBandwidth > > This is an max type constraint that specifies the > upper bound of the bandwidth > in kilobits per second. The default is a non mandatory > infinity. > > > I think these last 5 are more related to individual tracks than to > the session. (You might want to give an important video more CPU > than a less important one). > > > > > TODO > need to > sort out if this limit is for PeerConnection, Stream, > or Track. > > > WIth them added, the spec would look roughly like > > > > > > >
Received on Thursday, 31 January 2013 14:22:38 UTC