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 22:27:20 +0000
To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D12F684@xmb-aln-x12.cisco.com>
Hello Bernard

  Some thoughts inline.

From: Bernard Aboba [Bernard.Aboba@microsoft.com]
Sent: Friday, May 16, 2014 10:36 AM
To: Stefan Håkansson LK; public-webrtc@w3.org
Subject: RE: RTPSender/Receiver  - The case for Constraints

Stefan said:

"All of those constraints are applicable to the MediaStreamTrack that is added to the PeerConnection. "

[BA] Right.   Why apply those same constraints twice?

I do agree with you that no constraints are needed if the ones applied at the MST leave suffices for 
a given session. 

At the same time, I see a need to apply constraints on RTPEncoding(RTPStream) level for 
the reasons mentioned below

1. New constrainable attributes that applies only to the RTP Stream such as bandwidth, QOS,  and
goes along with the one defined at the track level (resolution, framerate).

2. The cases where we want PC to act as a Media Source Transform so that any such transformations
via constraints will not impact the originating media source and other associated sinks. 

3. I am aware we might not be interested in solving Simulcast/Layered coding like Multi-streams
per track at this point in time, but enabling RTPStream level constraints is quite useful to achieve
such a functionality.


Received on Friday, 16 May 2014 22:27:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC