TPAC 2018 was held last week in Lyon, France and attended by callstats.io. TPAC brings together W3C Technical Groups, the Advisory Board, the TAG, and the Advisory Committee for an exciting week of coordinated work. Many discussions were held on the progress and future of WebRTC, especially on day 1 and day 2. Read on to learn about the most noteworthy moments from TPAC 2018.
Major Push for WebRTC to Proposed Standard
Browser vendors are making a big push to get WebRTC v1.0 to Proposed Standard State (webrtc-pc and webrtc-stats). In order to succeed, every mandatory feature must be implemented by at least two browsers. When it comes down to brass tacks, this means the web-platform-test should pass, and there is a big push to introduce more web platform tests for WebRTC to increase coverage and reduce bugs in the specification.
Unified Plan Release Details
Unified Plan is set to be released by Chrome in January of 2019. The last remaining hurdle in the effort for webrtc-pc is simulcast. In order to mitigate the risk, W3C attempted to move simulcast into a separate spec (webrtc-simulcast). However, there was a concern that moving simulcast into a separate spec would make it tedious to implement, as developers would have to understand two specs instead of one (webrtc-pc and webrtc-simulcast).
In order to finalize simulcast in WebRTC v1.0, there are still several things that must be addressed. Stats have not been defined, the RID implementation is not complete, and testing simulcast is a challenge. A hackathon to test simulcast will be held sometime in March in conjunction with IETF.
WebRTC Feature Discussions
Several exciting features were discussed this week, including updates with SVC, FlexICE, QuicTransport, and others.
Scalable Video Coding (SVC) is added as part of the VP9 codec implementation in WebRTC, and will include a list of available dependency modes.
Work* was discussed at length. A conversation revolving around putting PeerConnection or individual objects inside a work* occured, with use cases and proposals presented by Apple, Mozilla, and Google. No decisions were made, beyond a suggestion to create prototypes and understand the complexity vs benefits of implementation.
QuicTransport has continued to evolve since this summer, with added support for unidirectional and bidirectional QuicStreams. A major change to the API is the move towards incorporation of WHATWG streams. If these are seriously considered, it could potentially impact the rest of the WebRTC APIs.
There is also a move towards the WHATWG Streams API. This will allow for data piping between one RTC object to another to give application developers flexibility and control over individual RTC objects while maintaining performance off of the main thread.
Additional WebRTC Use Cases
During breakout sessions, an incredible WebRTC use case was presented: immersive telepresence. This use case aims to focus on synchronization between media and haptic information, so WebRTC can be used for immersive telepresence and other practical applications. With its current design, however, this is not possible because there is no synchronization between data channels and media streams.
The team proposed the following:
An in-depth discussion on haptic format for Media Stream.
getUserMedia API enhancements and an API for getting haptic display.
We love to see new use cases of WebRTC still finding their way into the space today.
We have chosen to extend our membership with W3C for an additional year, and continue our work with webrtc-stats. In particular, we are focusing on v1.0 features, including simulcast and SCV statistics.
We also look to contribute to FlexICE. Fine-grained control of ICE aids our machine learning-based configuration service automatically choose the best path for media and data. QuicStreams and QuicTransport are evolving pieces that will carry media as early as 2020, and we are excited at the possibility that WebRTC-encoded media will present.