- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 28 Jan 2013 15:29:37 +0100
- To: public-webrtc@w3.org
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) 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 Monday, 28 January 2013 14:30:02 UTC