Archive | RTCWEB RSS for this section

W3C ORTC CG Meeting 10 underway

w3cScreen Shot 2015-11-20 at 10.57.13 AM

ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!

http://ortc.org/2015/11/04/w3c-ortc-cg-meeting-10-november-20-2015/

W3C ORTC CG Meeting 8

ORTC CG Meeting 8 will be held on May 13 at 10am – Pacific Daylight Time.

Where: Online WebRTC Enable Meeting via Jitsi (https://jitsi.tools.ietf.org/ortc) Reverted to Google Hangouts

Agenda:

W3C ORTC CG Meeting 7

22 January 2015 Editor’s draft:
http://ortc.org/wp-content/uploads/2015/01/ortc.html

Changes from the October 14 Editor’s Draft:

WebRTC 1.0 compatibility

  • Statistics API Update (Issue 85)
  • H.264 parameters update (Issue 158)
  • Support for maxptime (Issue 160)
  • RTCRtpUnhandledEvent update (Issue 163)
  • Support for RTCIceGatherer.state (Issue 164)

Do you really want a dual MTI video codec for WebRTC?

H.264 AVC for WebRTC VP8 - Webm

Update: There is now some healthy conversation in the IETF WG around what “compliant” and “compatible” actually mean. More on this as it unfolds.

We are now in the final throes of a consensus call in the IETF around which video codec should be made mandatory for those building WebRTC apps, services et al, who wish to be considered “WebRTC Compliant”. The codec contenders are VP8 and H.264, in many forms and combinations.

This latest consensus call is for both codecs to be mandated for all WebRTC endpoints, or “dual MTI codec”. I am sure I will catch hell from someone on language but that is the essence of it. As one might expect, there are some that are in favor and some that are against a dual MTI video codec. Those in favor seem motivated to accept this based on the promise of interoperability that might follow and other reasons. As one might expect, we are all quite eager to put this debate to bed so we could get on with other work.

This is not a decision that should be made lightly. Let’s consider the implications. Imposing a dual MTI suggests that every developer that wishes to produce a WebRTC compliant app must implement both codecs.

Coming from a co-founder of an RTC toolkit vendor I can tell you that this does not sit very well with me, nor others in the WebRTC WG. One glance at the thread comments should provide some insight.

I find it difficult to agree to mandate a dual MTI codec knowing that there are a great many developers who will not want or will be in a position to implement both codecs. Yes, many WebRTC SDK vendors will support both. Even if both codecs and their transports are provided as part or could be easily added to the application at compile time it doesn’t mean that every developer will want to implement or ship both codecs.

Bottom line is, according this consensus, if developers do not implement/ship both codecs they are not considered WebRTC compliant. To me, this seems like a rather unreasonable expectation. Developers should be able to choose which codec they ship, and not be forced to do 2x the work to become compliant.

I would love to hear from other developers on this. Do you plan on implementing both VP8 and H.264 in your apps?

Hookflash, Google and Microsoft lead on ORTC / WebRTC 1.1 Public Draft

webrtc1.1_logo

The first ORTC Public Draft Specification has been published, authored by Hookflash, Microsoft, and Google. (http://ortc.org/wp-content/uploads/2014/08/ortc.html ) This specification extends WebRTC 1.0 with new functionality to create a WebRTC 1.1 API with exceptional flexibility and no loss of compatibility.

Like WebRTC, ORTC (Object Real-time Communication) enables plugin-free real-time communications for mobile, web and cloud, but is specifically tailored to provide the direct control needed to enable advanced multimedia and conferencing features.

“We heard developers say that they wanted more direct control over the technologies available in WebRTC. At the same time, we didn’t want existing developers to have to start over with a new API. ORTC is our proposal for how we can accomplish both of these things – a new set of APIs for direct control, that builds off the existing WebRTC 1.0 API set. As an evolution of the existing API, we consider this WebRTC 1.1” comments Justin Uberti, Google Tech Lead, WebRTC. “We’re grateful to Hookflash for their work to get ORTC off the ground. They have been instrumental in making this cross-industry collaboration happen, and we look forward to continuing our work with them.”

This newly published public draft has come a long way since the W3C ORTC Community Group was formed in mid-2013. As it has progressed from an initial set of ideas to a fleshed-out draft complete enough for implementations, several companies have gotten closely involved, with Microsoft and Google now joining Hookflash as authors of the emerging specification.

“We have been working hard to get the ORTC API to the point where it can be implemented. This would not have been possible without the initial and continuing work of Hookflash”, commented Bernard Aboba, Principal Architect, Skype, “We also are excited by the ORTC API’s support for advanced video features such as SVC (Scalable Video Coding) and simulcast. The Javascript Object API approach has made these advanced video technologies more accessible, which has been difficult in the past.”

The W3C ORTC Community Group now numbers more than 60 participants.

“We believe the contributions to WebRTC 1.1 / ORTC will allow web communications technology to become ubiquitous and transcend nearly all communications technologies that came before it” says Hookflash Co-founder, Erik Lagerway, “We are honored to be working with some of the brightest minds at Google, Microsoft, and the other contributing members in the ORTC CG to mature WebRTC into a universal go-to toolkit enabling communications across the globe.”

For more information on ORTC, see:
W3C ORTC Community Group
ORTC.org – History and FAQs
WebRTC.is – ORTC & WebRTC news

Hookflash enables real-time social, mobile, and web communications for integration of voice, video, messaging with federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc.

Developers can register at (http://fly.hookflash.me) to start using the Hookflash RTC service and toolkits today. For more information on Hookflash RTC toolkits and White Labeling please visit Hookflash http://hookflash.com.

Come and work at one of the coolest companies in the space! We’re now hiring for these development positions: iOS, Android, Node.js & C++ send us your resume: jobs@hookflash.com.

Hookflash – Trent Johnsen
855-466-5352 Ext: 1

ORTC API Editor’s Draft – Last Call & WebRTC WG

ORTC - Object RTC

The W3C ORTC Community Group has published an Editor’s Draft update to the ORTC API and is also asking for last call comments on the draft…

We are nearing completion of the ORTC specification for our initial ORTC community group draft. We are asking for last call feedback at this time. Some comments to explain some of the changes are still pending but all issues are tracked here and on github. If you would like to make comment, please have a read through and make comment either on this list or as part of our next CG meeting coming up.

There are a few outstanding areas which are “pending” synchronization with WebRTC, e.g. stats, data channel, and IdP. As these have dependencies on WebRTC 1.0, we will attempt to complete the our specification as best we can but those areas will be subject to synchronization should updates come out of the WebRTC community group.

Now is the time to have a read through for final review as the next stage will be to build implementations for implementation feedback.
So what does that mean?

Well, likely the most important takeaway is the fact that this spec now looks to be in a form where it could be implemented. The ORTC Libs (https://github.com/openpeer/ortc-lib) have been in stasis while the CG worked on getting the spec further along. Now that the CG is very close to a public draft on the API spec, that work will resume.

Something else that may be of interest is the direct reference to the W3C WebRTC Working Group in this draft and the issue tracker. There are a few components that require progress in the WebRTC WG before the ORTC CG can implement them. Now there seems to be a direct correlation between the work being done in the ORTC CG and the WebRTC WG, which should really not come as any great surprise to anyone.

At the last meeting, the CG discussed “What is the ORTC CG end game?” The resulting conversation equated to an answer that sounded something like, “Let’s create an implementable API, then if the WebRTC WG is interested in seeing the work being done in the ORTC CG merged into the WG then we should be happy to explore that.”  There was no definite objection apart from, “let’s make sure the timing is right and it makes sense to do that”.

So if you are fuzzy on where the ORTC CG is headed, you should really check out that video clip.

%d bloggers like this: