Almost 6 years ago, we took the initiative to bring real time communication to the Web platform. Thanks to the industry-wide adoption of WebRTC, the majority of browsers now offer developers access to high-quality audio, video and data communication using a common set of APIs. These APIs have made the web platform more powerful and helped eliminate the need for browser plugins.
Along the way, we have reached consensus on programming models, network protocols, and, of course, video codecs. With this work largely behind us, and most browser implementations nearing completion, we plan to make a significant push to finish WebRTC 1.0 this year.
This effort will be fourfold:
Complete the WebRTC 1.0 specifications in both the W3C and IETF
As one of the key contributors to these specifications, we aim to resolve the remaining gaps so that these documents can be published.
Resolve remaining major spec incompatibilities in Chrome’s implementation
We will address the key areas where our implementation does not conform to the WebRTC 1.0 specifications. In particular, this will include:
Adding support for RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver
Transitioning from Plan B to Unified Plan SDP
Improving conformance for getStats identifiers
Ensure interoperability across all browsers
With browser vendors increasingly relying on Web Platform Tests for compliance, we are developing a WPT test suite for the WebRTC specification. In addition, we aim to release a system for testing cross-browser interoperability at the API and protocol level, including complex interworking scenarios.
Resolve remaining reliability pain points
WebRTC powers thousands of apps with hundreds of millions of users, but we are always working on making the platform more robust. As part of this initiative, we plan to complete several significant infrastructure improvements that will reduce audio echo and glitches, and provide improved resiliency against camera or microphone issues caused by the device or OS.
We’re incredibly proud of the success that WebRTC has attained in the industry. With the efforts outlined above, we aim to complete our mission of providing a standardized, high performing, and stable communications platform, and fully deliver on WebRTC's promise.
2017-05-19 12:57 GMT+02:00 'Huib Kleinhout' via discuss-webrtc
> Resolve remaining major spec incompatibilities in Chrome’s implementation
> We will address the key areas where our implementation does not conform to
> the WebRTC 1.0 specifications. In particular, this will include:
>
> Adding support for RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver
>
> Transitioning from Plan B to Unified Plan SDP
So nice to hear that. Thanks.
--
Iñaki Baz Castillo
<i...@aliax.net>
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfnUyr0Y8LGwuCBAS5WdJz%3DR9i4UYxQSpv-Bw-8w3N9VOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Thanks Huib.
Looking at understanding in the detail the specifics of #3, are scenarios including the use of SFUs for instance in between, e.g. for multiparty?
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/36995daf-baf0-4dd3-a6cb-44aea3259cfe%40googlegroups.com.
Almost 6 years ago, we took the initiative to bring real time communication to the Web platform.
Resolve remaining major spec incompatibilities in Chrome’s implementation
We will address the key areas where our implementation does not conform to the WebRTC 1.0 specifications. In particular, this will include:
Adding support for RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver
Transitioning from Plan B to Unified Plan SDP
Improving conformance for getStats identifiers
Ensure interoperability across all browsers
With browser vendors increasingly relying on Web Platform Tests for compliance, we are developing a WPT test suite for the WebRTC specification. In addition, we aim to release a system for testing cross-browser interoperability at the API and protocol level, including complex interworking scenarios.
We’re incredibly proud of the success that WebRTC has attained in the industry. With the efforts outlined above, we aim to complete our mission of providing a standardized, high performing, and stable communications platform, and fully deliver on WebRTC's promise.
Huib, speaking for Google
Thank you Huib, That's really great!Can you clarify if these things are also going to be included?
- Standard simulcast support (at API, SDP and RTP level)
- TMMBR for remote bitrate control.
- Congestion control (REMB, transport-cc, xr reports....) Is it out of the scope of 1.0?
Regards,
El vie., 19 may. 2017 a las 12:57, 'Huib Kleinhout' via discuss-webrtc (<discuss-webrtc@googlegroups.com>) escribió:
--Almost 6 years ago, we took the initiative to bring real time communication to the Web platform. Thanks to the industry-wide adoption of WebRTC, the majority of browsers now offer developers access to high-quality audio, video and data communication using a common set of APIs. These APIs have made the web platform more powerful and helped eliminate the need for browser plugins.
Along the way, we have reached consensus on programming models, network protocols, and, of course, video codecs. With this work largely behind us, and most browser implementations nearing completion, we plan to make a significant push to finish WebRTC 1.0 this year.
This effort will be fourfold:
Complete the WebRTC 1.0 specifications in both the W3C and IETF
As one of the key contributors to these specifications, we aim to resolve the remaining gaps so that these documents can be published.Resolve remaining major spec incompatibilities in Chrome’s implementation
We will address the key areas where our implementation does not conform to the WebRTC 1.0 specifications. In particular, this will include:
Adding support for RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver
Transitioning from Plan B to Unified Plan SDP
Improving conformance for getStats identifiers
Ensure interoperability across all browsers
With browser vendors increasingly relying on Web Platform Tests for compliance, we are developing a WPT test suite for the WebRTC specification. In addition, we aim to release a system for testing cross-browser interoperability at the API and protocol level, including complex interworking scenarios.Resolve remaining reliability pain points
WebRTC powers thousands of apps with hundreds of millions of users, but we are always working on making the platform more robust. As part of this initiative, we plan to complete several significant infrastructure improvements that will reduce audio echo and glitches, and provide improved resiliency against camera or microphone issues caused by the device or OS.
We’re incredibly proud of the success that WebRTC has attained in the industry. With the efforts outlined above, we aim to complete our mission of providing a standardized, high performing, and stable communications platform, and fully deliver on WebRTC's promise.
Huib, speaking for Google
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/36995daf-baf0-4dd3-a6cb-44aea3259cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAPx8CAZCQbrtPVZCNW0T3FVxbhUt0ViRQf3qkrVE29BeRe4VJQ%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
On Fri, May 19, 2017 at 11:55 AM, Gustavo García <gust...@gmail.com> wrote:Thank you Huib, That's really great!Can you clarify if these things are also going to be included?
- Standard simulcast support (at API, SDP and RTP level)Yes.
On Fri, May 19, 2017 at 11:55 AM, Gustavo García <gust...@gmail.com> wrote:Thank you Huib, That's really great!Can you clarify if these things are also going to be included?
- Standard simulcast support (at API, SDP and RTP level)Yes.
- TMMBR for remote bitrate control.Not currently planned, but we will consider based on developer demand.
- Congestion control (REMB, transport-cc, xr reports....) Is it out of the scope of 1.0?This is supported today; transport-cc is the preferred mechanism.
Regards,
El vie., 19 may. 2017 a las 12:57, 'Huib Kleinhout' via discuss-webrtc (<discuss...@googlegroups.com>) escribió:
--Almost 6 years ago, we took the initiative to bring real time communication to the Web platform. Thanks to the industry-wide adoption of WebRTC, the majority of browsers now offer developers access to high-quality audio, video and data communication using a common set of APIs. These APIs have made the web platform more powerful and helped eliminate the need for browser plugins.
Along the way, we have reached consensus on programming models, network protocols, and, of course, video codecs. With this work largely behind us, and most browser implementations nearing completion, we plan to make a significant push to finish WebRTC 1.0 this year.
This effort will be fourfold:
Complete the WebRTC 1.0 specifications in both the W3C and IETF
As one of the key contributors to these specifications, we aim to resolve the remaining gaps so that these documents can be published.Resolve remaining major spec incompatibilities in Chrome’s implementation
We will address the key areas where our implementation does not conform to the WebRTC 1.0 specifications. In particular, this will include:
Adding support for RTCRtpTransceiver, RTCRtpSender, and RTCRtpReceiver
Transitioning from Plan B to Unified Plan SDP
Improving conformance for getStats identifiers
Ensure interoperability across all browsers
With browser vendors increasingly relying on Web Platform Tests for compliance, we are developing a WPT test suite for the WebRTC specification. In addition, we aim to release a system for testing cross-browser interoperability at the API and protocol level, including complex interworking scenarios.Resolve remaining reliability pain points
WebRTC powers thousands of apps with hundreds of millions of users, but we are always working on making the platform more robust. As part of this initiative, we plan to complete several significant infrastructure improvements that will reduce audio echo and glitches, and provide improved resiliency against camera or microphone issues caused by the device or OS.
We’re incredibly proud of the success that WebRTC has attained in the industry. With the efforts outlined above, we aim to complete our mission of providing a standardized, high performing, and stable communications platform, and fully deliver on WebRTC's promise.
Huib, speaking for Google
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/36995daf-baf0-4dd3-a6cb-44aea3259cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAPx8CAZCQbrtPVZCNW0T3FVxbhUt0ViRQf3qkrVE29BeRe4VJQ%40mail.gmail.com.
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOJ7v-3LBv2wmgT1%3DZU-jknqpJv46wc2ugQne%2Bb%2B9HgVia3CKQ%40mail.gmail.com.
El 8 jun 2017, a las 15:54, Gustavo García <gust...@gmail.com> escribió:- TMMBR for remote bitrate control.Not currently planned, but we will consider based on developer demand.I remember a conversation (Twitter) where 4-5 SFU developers mentioned that it was important for them. It is tracked here if you want to consider it:
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/16867bce-46bc-4785-9cc0-1a73081999ea%40googlegroups.com.
now if transport-cc was implementable without having to resort to reverse-engineering... https://bugs.chromium.org/p/webrtc/issues/detail?id=7409
2017-06-09 9:26 GMT+02:00 mparis <mpari...@gmail.com>:
Nice to hear that, at least, Chrome people is going to consider TMMBR support.
It will be more than useful, it will be necessary to implement features requested by real customers due to TMMBR is the standard way and REMB will be deprecated and replaced by transport-cc (as some of us pointed out in the Twitter conversation).
Gustavo, thank for commenting it in this thread ;).
El jueves, 8 de junio de 2017, 17:55:23 (UTC+2), Luis Lop escribió:
El 8 jun 2017, a las 15:54, Gustavo García <gust...@gmail.com> escribió:- TMMBR for remote bitrate control.Not currently planned, but we will consider based on developer demand.I remember a conversation (Twitter) where 4-5 SFU developers mentioned that it was important for them. It is tracked here if you want to consider it:+1 (now 6 SFU developers)L.
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
Almost 6 years ago, we took the initiative to bring real time communication to the Web platform. Thanks to the industry-wide adoption of WebRTC, the majority of browsers now offer developers access to high-quality audio, video and data communication using a common set of APIs. These APIs have made the web platform more powerful and helped eliminate the need for browser plugins.