- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 31 Jan 2013 15:42:17 +0100
- To: public-webrtc@w3.org
- Message-ID: <510A82C9.2090204@alvestrand.no>
Another part of my thinking: If it's just an SDP manipulation thing, it can go on the SDP object. If it requires the browser to adjust multiple things in synchrony, I prefer constraints. On 01/31/2013 03:22 PM, Harald Alvestrand wrote: > 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:42:48 UTC