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 10:15:35 UTC