W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

Re: Fwd: Proposal for some constrains we need

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 28 Jan 2013 15:29:37 +0100
Message-ID: <51068B51.9080807@ericsson.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC