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

Re: Fwd: Proposal for some constrains we need

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 31 Jan 2013 15:42:17 +0100
Message-ID: <510A82C9.2090204@alvestrand.no>
To: public-webrtc@w3.org
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

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