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

Re: RTPSender/Receiver - The case for Constraints

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 16 May 2014 11:58:59 +0000
To: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFE5B81@ESESSMB209.ericsson.se>
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.)

(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?)
Received on Friday, 16 May 2014 11:59:24 UTC

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