- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 08 Dec 2013 17:05:47 +0100
- To: cowwoc <cowwoc@bbs.darktech.org>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Gili, have you read draft-alvestrand-constraints-resolution-03? At the moment, as I've told you before, we have no agreement on how to do signalling over the wire. So there is no mechanism in place to do option 2 or 3 of the 3 options described in section 3 of that document. We have agreement on how to set constraints at the source (as described in option 1). As far as I know, none of the browsers have implemented that feature yet, though - but the spec is written. On 12/02/2013 09:38 PM, cowwoc wrote: > Hi Martin, > > Apologies, but I think we are misunderstanding each other. Just to be > 100% clear, I am trying to do this: > > "Sender" sends "Receiver" video at 1080p > "Receiver" only needs 640x480, so I want "Receiver" to execute some > code on its side that will tell "Sender" to stop sending 1080p and > instead send 640x480 over the wire. > The goal is to reduce bandwidth usage. > > I suspect the following answers no longer make sense in light of the > above problem definition. > > On 02/12/2013 2:23 PM, Martin Thomson wrote: >> On 2 December 2013 11:19, cowwoc <cowwoc@bbs.darktech.org> wrote: >>> Why do I need to clone() the video track before modifying it? >> I assumed that you might want to keep the old one. > > Why would I want Sender to send me the same stream twice? If I really > wanted to display the same video using two different resolutions, I'd > send the video once over the wire and scale it on Receiver's end. > >>> What is the relationship between a cloned VideoTrack and the original >>> MediaStream? >> No relationship. The new track is a little orphan. You'll need a new >> stream to house this track if you want to use it though. > > <confused> How could Receiver create a new stream and associate the > track with it? Don't I need this track to be connected to Sender somehow? > > Thanks, > Gili >
Received on Sunday, 8 December 2013 16:06:17 UTC