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

Re: Update of RTCRtpSender "doohickey" proposal

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 1 May 2014 22:09:17 -0700
Message-ID: <CABkgnnVnyZk503B-6iAsA2S=j+UPyEexgLgZUxVq7ubmZSfeSg@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Cc: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Justin Uberti <juberti@google.com>
On 1 May 2014 19:41, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> The MST is the API where we can set things like resolution, framerate, etc.
>> Assume you want to record the same content in two different resolutions,
>> they way to do it today would be to clone the track, and apply different
>> settings, and record both IIUC.
>> Sure, we could move the surface where you define desired framerate,
>> resolution, etc. to the consumer all together - but that would be a big
>> change quite late.
> Good point. Nope - I don’t want to do any chances that large right now. Current design will get the job done so no real advantage to changing.

Yeah, but my concern was with respect to implicit cloning.  We had, on
and off, this idea that when a track is added to RTCPeerConnection, it
would be cloned and the thing that the RTCPeerConnection owned would
be a clone of that track with extra properties.  That's what I wanted
to avoid.

The idea that you can clone a track outside of this, and apply
different constraints is a pretty useful concept and one that I think
we've invested enough effort into already.  I really don't want to
change (i.e. regress) any of that stuff now.
Received on Friday, 2 May 2014 05:09:45 UTC

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