fully agree, although at the end all browsers may end up using same libwebrtc mechanism. BR Sergio El sáb., 15 dic. 2018 11:16, Varun Singh <varun@callstats.io> escribió: > Is there really a reason to specify when or how to use a particular > resilience scheme as long as endpoints implement the ones that have been > mandated in the rtcwen-RTT-usage draft are implemented? > > I believe that how and when a resilience scheme is used is basically an > app behavior (mobile apps may do something different from the common > baseline behavior, and apps that are more content aware might choose to do > something all together different as well.) > > I think apps should be able to freely use the mechanisms available in the > toolbox. > > On Sat, 15 Dec 2018 at 3.31, Bernard Aboba <Bernard.Aboba@microsoft.com> > wrote: > >> We should probably rexamine WebRTC robustness more systematically, >> because we can do quite a bit better than what is there now. >> >> IMHO, for Opus, RED applied judiciously outperforms Opus FEC (which >> cannot handle burst loss). >> >> For video, differential protection (e.g. RTX or FEC on base layer only) >> is more efficient than applying FEC or RTX to all bits. >> >> > On Dec 14, 2018, at 6:25 PM, Cullen Jennings <fluffy@iii.ca> wrote: >> > >> > >> > I don’t know why we ever put RTX in WebRTC - it was clearly so >> suboptimal in RTP in general that we created much better things to replace >> it - like ULPFEC. I’d be in favor of removing it. >> > -- > Founder, CEO, callstats.io > http://www.callstats.io > > Interested in networking, media quality, and diagnostics. > We are hiring!: www.callstats.io/jobs/ >
Received on Saturday, 15 December 2018 11:22:11 UTC