Completing WebRTC 1.0
Huib Kleinhout
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.
Iñaki Baz Castillo
<discuss...@googlegroups.com>:
> 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
--
Iñaki Baz Castillo
<i...@aliax.net>
Oscar Divorra Escoda
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.
Huib Kleinhout
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?
Gustavo García
- Standard simulcast support (at API, SDP and RTP level)
- TMMBR for remote bitrate control.
--
---
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.
Saúl Ibarra Corretgé
This is great news, thanks for sharing! Could you elaborate a bit on how the transition from plan B to unified is going to look like for users? I can imagine it’s not going to happen overnight, so is there going to be a custom constraint to trigger plan B for a while or are there any other plans?
Cheers,
--
Saúl
Tim Panton
On Friday, 19 May 2017 11:57:09 UTC+1, Huib Kleinhout wrote:
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
Also will you be removing the (slightly hidden) support for non-spec SDES-SRTP ?
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
Amir Zmora
wpp
Chunbo Hua
Rahul Pathak
dong tim
在 2017年5月19日星期五 UTC+8下午6:57:09，Huib Kleinhout写道：
Justin Uberti
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.
Iñaki Baz Castillo
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.
Gustavo García
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.
Luis Lopez
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:
mparis
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 ;).
Philipp Hancke
--
---
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.
OscarD
On Friday, June 9, 2017 at 9:32:37 AM UTC+2, Philipp Hancke wrote:
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.
Iñaki Baz Castillo
> @Justin, following further the comments on the matter, and in line with
> domain colleagues in the thread, unless I miss something, I believe:
> Even if transport-cc may be the preferred mechanism from the sole Chrome
> perspective, at system/platform level, and considering WebRTC ecosystem
> including SFUs, in practice, I think transport-cc appears as non-preferred
> currently, for the reasons that have already been discussed through the
> different channels and issues already reported .
sender. REMB can do that but if we ask about REMB some IETF writer
will complain because REMB was abandoned (no matter that even Edge
implements it). TMMBR is the only *standard* way for artificially
limiting the bitrate of a sender. No, I don't even consider the SDP
a=b:AS stuff (that's not dynamic).
So yes, transport-cc is so cool, but it does NOT provide what many
developers need.
Sergio Garcia Murillo
From my point of view transport-cc and TMMBR are like apple and oranges..
We need transport-cc for up bandwidth estimation and TMMBR for
application level bandwidth control. REMB on the other side was used for
both functions, and that's why it was the preferred mechanism for SFU
devs, although IMHO transport-cc will provide a much better BWE than the
one possible via REMB, but we still need TMMBR.
Best regards
Sergio
Iñaki Baz Castillo
<sergio.gar...@gmail.com>:
> level bandwidth control. REMB on the other side was used for both functions,
> and that's why it was the preferred mechanism for SFU devs, although IMHO
> transport-cc will provide a much better BWE than the one possible via REMB,
> but we still need TMMBR.
would prefer transport-cc (easier to implement in server side) plus
TMMBR rather than REMB. But, it happens that browsers do not implement
TMMBR and just Chrome implements transport-cc.
sam
open264 codec support SVC,only need to modify mparam.iTemporalLayerNum = 4 in (webrtc/modules/video_coding/codecs/h264/h264_impl.cc) ,
and add temporal infomation in rtp extention,so the SFU or MCU can use SVC ,
maybe sometimes peerconnection add flag to support h264 SVC?
thanks
在 2017年5月19日星期五 UTC+8下午6:57:09，Huib Kleinhout写道：
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.