- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Fri, 2 May 2014 02:41:41 +0000
- To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Justin Uberti" <juberti@google.com>
On May 1, 2014, at 4:17 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote: > On 30/04/14 22:23, Cullen Jennings (fluffy) wrote: >> >> On Apr 29, 2014, at 6:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote: >> >>> >>> On Apr 29, 2014 4:54 PM, "Jan-Ivar Bruaroey" <jib@mozilla.com> wrote: >>>> >>>> On 4/29/14 7:07 PM, Martin Thomson wrote: >>>>> >>>>> I was talking about clone-on-RTCPeerConneciton::addStream >>>> >>>> >>>> Forcing me, as a user, to clone my MST if, and only if, I want to add it to more than one PeerConnection seems to have little to no cost to me, and seems like a reduction in complexity. >>> >>> I might be missing something, but why do we need cloning? >>> >> >> I assumed we would get rid of cloning once we added doohickeys. > > 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.
Received on Friday, 2 May 2014 02:42:10 UTC