RE: What would you like to see in WebRTC next? A low-level API?

Justin said: 

"This is a reasonable take. On this topic, one thing that I continually hear from developers: they want more control over their destiny, e.g. to get consistent performance across browsers, and even across versions of individual browsers.

Peter's proposal takes allows the developer to own much more of the code that is actually running in a WebRTC call. This not only allows for more innovation, but also provides a much deeper level of control."

[BA] Consistency across browsers and releases is definitely a pain point, particularly for the more advanced functionality utilized in centralized conferencing. 

In part, this is what is driving the growth of frameworks such as Electron - the desire to control risk for the application developer (which, ironically, can lead to an explosion in the test matrix for browser developers). 

Frameworks like KITE are potentially helpful. But ever-growing test matrices have a way of overwhelming even the best test tools. 

So if we have a choice between adding complex and hard to test features, or adding simple and easy to test features on which more complex things can be built, we should definitely choose the latter. 

In terms of what is causing headaches, a year ago, a lot of debugging time was spent on ICE, but more recently, interactions between browsers and centralized conferencing servers (e.g. RTP/RTCP routing, feedback/congestion control, simulcast, SVC) have been catching up.  It wouldn't surprise me if features such as frame-marking, MIDs and RIDs add fuel to this growing fire.

Received on Wednesday, 24 January 2018 07:43:51 UTC