Re: Update of RTCRtpSender "doohickey" proposal

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