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

Re: Update of RTCRtpSender "doohickey" proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 02 May 2014 10:26:32 +0200
Message-ID: <536356B8.5060401@alvestrand.no>
To: public-webrtc@w3.org
On 05/02/2014 07:22 AM, Stefan Håkansson LK wrote:
> On 02/05/14 07:09, Martin Thomson wrote:
>> 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.
> I agree fully (and I haven't seen anyone having a different view).
I've not encountered this proposal, it's not how things work now, and it 
would be an incompatible change of some brutality.

If you create a track, set track.enabled=false, connect it to an 
RTCPeerConnection, and set track.enabled=true, the media will start to 
flow (switch from blackness to image).

If the PC had a clone of the track, directly connected to the source, 
this would not happen.

The reason the doohickey control was seen as valid was because "I send 
packets (doohickey control)" is a different concept from "I send images 
(track control)". At least that's what I took away from Seattle/Shenzhen.
Received on Friday, 2 May 2014 08:27:01 UTC

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