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

Re: Handling simulcast

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 7 Sep 2013 10:59:44 +0000
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C38774D@ESESSMB209.ericsson.se>
On 2013-09-06 20:25, Harald Alvestrand wrote:
> On 09/06/2013 07:40 PM, Martin Thomson wrote:
>> On 6 September 2013 10:29, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> It's not the lack of proposals that is preventing forward movement.....
>> You can scratch a=inactive, since in the unified plan, both simulcast
>> streams will appear on the same m-line.  Though that would require
>> that the browser know that the two tracks are the "same", which leads
>> to a similar problem.
> Yep, the "JS-driven" approach would have them appear on different
> m-lines, since they're different tracks in all aspects until they hit
> the playback entity. That's not what's been hinted at in the
> unified-plan document.
> The other approach - handling the whole simulcast thing with either
> layered codecs or other means "under the covers" - has attractive
> features from a browser perspective (because it means one can utilize
> all mechanisms the browser has available) and from the JS perspective
> (because the only thing one has to do for simulcast is ask for it) - but
> since the "js-driven" approach has been raised, I think it's good to
> explore it.

I think the "under the hood" model is attractive and something we should 
pursue (but I don't know if it should be in v1 though).  My point was 
rather that we already have some support for (js-driven) simulcast.


Received on Saturday, 7 September 2013 11:00:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC