- 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>
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