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