W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2013

Re: Handling simulcast

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Fri, 6 Sep 2013 17:38:19 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11669279D@xmb-aln-x02.cisco.com>

As an alternative proposal, how about a constraint that has roughly this semantic information:

1920x1080 30fps 3Mbps, 1280x720 30 fps 1Mbps, 525x700 30fps 256kbps 

To specify 3 layers with max bitrates as specified. 

The point Justin has made before is the solution below won't work for layered codecs and it would be nice to have the JS code be the same and let the browser take care of negotiating if we use simulcast or layered codecs. 

I'm just tossing ideas out there but it seems like whatever we do, be nice if it was reasonably easy for JS programmmers to use. I could probably live with something along the lines of what you suggested bellow. 

On Sep 5, 2013, at 11:31 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> There was a question about how to do simulcast on the call.  Here's
> how it might be possible to do simulcast without additional API
> surface.
> 1. Acquire original stream containing one video track.
> 2. Clone the track and rescale it.
> 3. Assemble a new stream containing the original and the rescaled track.
> 4. Send the stream.
> 5. At the receiver, play the video stream.
> That's the user part, now for the under-the-covers stuff:
> I know we discussed the rendering of multiple video tracks in the
> past, but it's not possible to read the following documents and reach
> any sensible conclusions:
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html
> http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource
> What needs to happen in this case is to ensure that the two video
> tracks are folded together with the higher "quality" version being
> displayed and the lower "quality" version being used to fill in any
> gaps that might appear in the higher "quality" one.
> That depends on the <video> element being able to identify the tracks
> as being equivalent, and possibly being able to identify which is the
> higher quality.  This is where something like the srcname proposal
> could be useful
> (http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname-02).
> The only missing piece is exposing metadata on tracks such that this
> behaviour is discoverable.  Adding an attribute on tracks (srcname
> perhaps, arbaon), could provide a hook for triggering the folding
> behaviour I'm talking about.
Received on Friday, 6 September 2013 17:38:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC