W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

RE: RTPSender/Receiver - The case for Constraints

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Fri, 16 May 2014 17:05:24 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D12EE39@xmb-aln-x12.cisco.com>

From: Stefan Håkansson LK [stefan.lk.hakansson@ericsson.com]
Sent: Friday, May 16, 2014 4:58 AM
To: Suhas Nandakumar (snandaku); public-webrtc@w3.org
Subject: Re: RTPSender/Receiver  - The case for Constraints

On 15/05/14 20:40, Suhas Nandakumar (snandaku) wrote:
> Here is an attempt on explaining the applicability of constraints in the
> context of RTPSender/Receivers. Please note that the below proposal
> doesn't touch upon DtlsTransport/Transport related objects from the
> earlier proposals.
> Many thanks to Jim Barnett for helping develop the below proposal.
> Case for Constraints:
> ----------------------
> Example : One way video session
> This is a simple example that shows the applicability of constraints in
> successfully negotiating a one way video session where, Alice is the
> Media Sender and Bob is the Media Receiver.
> Alice can send a video RTP stream with the following configuration
>    - Aspect ratio between 1.0 and 2.0
>    - Frame-rate ranges 20 - 60 FPS
>    - bit-rate ranging from 0.5 to 3 Mbps
>    - She wants 640 X 480 as the minimum resolution and 1080p as the
> preferred resolution with 30 FPS as the associated frame rate.
> Alice might use following constraint specification to share her proposal
> with Bob.
> var alice_constraints {
>    require:   ["width", "height"]
>    width:     {min: 640},
>    height:    {min: 480},
>    framerate: {min:20, max: 60},
>    aspectRatio: {min:1.0, max:2.0}
>    advanced     [{width: 1920, height: 1080},
>                 {framerate:30}]
>   };

All of those constraints are applicable to the MediaStreamTrack that is
added to the PeerConnection. In my mind I had a model where the
RTPSender would offer complementary APIs related to transport of the net
(e.g. pause sending, settings for simulcast/layered coding, etc.)

[Suhas] PeerConenction in itself is a MediaSource that should be able to
apply any transformations as needed to the over the network media as
driven by the negotiation. The inherent nature of these attributes is that,
in general cases, the specific value can vary over time in a given session. 
As long as the values fit within the negotiated ranges, the peers should be
able to inter-operate. A simple example would be a negotiated aspectRatio
of 4:3 which might correspond to any of the resolutions such as 640X480,
1280X960, 1920 X 1080. Thus giving UA the flexibility in choosing appropriate
values for resolutions, frameRates that falls with in the agreed upon aspectRatio
and bandwidth requirements under dynamic operating conditions is what we 
should be allowing to do. This also has the good side-effect of freeing the
application developer from managing these ranges and their variability in their

(I also think the relation between the width/height constraints of the
track and the width/height of the consumer - Recorder or video element -
is confusing; but that is another story)

> //example usage - as a result of this, the next createOffer()
> //generates SDP that takes care into account the above constraints.
> Pc.getRTPSenders()[0].applyConstraints(alice_constraints);
> Bob wishes to receive the video stream with these characteristics
>    - Can support 4:3 as the single Aspect ratio.
>    - Max recv video resolution 1024 X 768.
>    - He prefers 630 X 480 video resolution.

An alternative would be that this is set at the sender side. As Tim
pointed out, in 99% of the cases it will be the same app at both ends.

(Of course there needs to be a negotiation regarding what the end points
support, but is not that handled by the SDP O/A itself?)

[Suhas] The constraints are indeed influencing the SDP Offers and Answers
Received on Friday, 16 May 2014 17:06:04 UTC

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