Re: Fwd: Proposal for some constrains we need

On 2013-01-31 08:21, 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.

I think we embarked on the constraint route as a result of the feedback 
on the (change) settings API proposals that have been developed by 
Travis. In the early versions there were specific api calls for each 
property to set, but the feedback from the group has consistently been 
that we should use constraints.

Still, in the latest iteration [1], you can (in addition to work with 
the entire constraint set) change a specific property without having to 
supply a full constraint set:

setConstraint(constraint_name, value);

I think this is a reasonable design compromise.


>
> 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.
>

We could do this on SessionDescriptions, but the drawback is that we 
would need two surfaces as there are a lot of stuff that never enter the 
SDP but only affects the local processing (like, for example, CPU to 
spend on encoding).

It could also be argued that if we decouple the SessionDescriptions as 
much as possible from the API methods, we could come quicker to stable 
APIs, and allow how they affect the SDPs and so on be discussed by 
mmusic and others for some time without having the result break the 
applications. I don't know how valid this is.

Stefan

[1] 
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
>
>
>
>
>
> 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 09:36:05 UTC