W3C ORTC CG Meeting 10 underway
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:
- Review Bugs:
https://github.com/openpeer/ortc/issues?q=is%3Aopen - Review current draft
http://ortc.org/wp-content/uploads/2015/05/ortc.html - Stefan requested we comment on this…
The WebRTC and Device APIs Working Groups request feedback on the Last Call Working Draft of Media Capture and Streams, a JavaScript API that enables access to cameras and microphones from Web browsers as well as control of the use of the data generated (e.g. rendering what a camera captures in a html video element):
http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ - CG alignment with 1.0
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?
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
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
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 if you are fuzzy on where the ORTC CG is headed, you should really check out that video clip.
W3C & IETF | WebRTC – Joint Face to Face Meeting
There might be a joint IETF/W3C WebRTC F2F meeting in May, somewhere on the North American East Coast.
From the W3C Chairs…
——
There has been some feedback on the dates. We propose to shift the
potential f2f meeting one day earlier to reduce the overlap with a 3GPP
meeting.
The proposed dates for the meeting is therefore 19-21 of May (Mon-Wed).
Stefan for the chairs
On 2014-01-29 09:20, Stefan Håkansson LK wrote:
> Hi all – and sorry for cross-posting!
>
> The chairs of the WebRTC WG (and the Media Capture TF) and the chairs of
> the IETF rtcweb WG are considering an joint f2f meeting. The dates we
> chairs have arrived on as feasible are May 20-22 (Tue-Thu). We are
> considering to split up the time between W3C and IETF across all three
> days. We have not yet discussed how to split the W3C time between WebRTC
> and the Media Capture TF at all yet (and perhaps we end up in focusing
> on the WebRTC WG since that part would probably benefit most from a
> joint meeting with the IETF rtcweb WG).
>
>
> The message at this stage is: please take note of these dates in your
> calendar now.
>
> The target region for this interim would be East Coast of North America,
> but we have at this stage no host or set location. If you are willing to
> host, please contact the chairs.
>
> We haven’t decided on this f2f meeting yet, and appreciate your input
> into holding one. The goals of the meeting would be to advanced the
> state of the core documents we need to finish up.
>
> Stefan for the chairs
>
The first ORCA CG meeting!
Here are the ORCA Community Group meeting details for our very first CG meeting.
Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)
Location: Hangouts
Agenda
===============
• Introduction to the CG
• Quick review of progress to date
• Overview of meeting objectives
– Existing proposals review
– New proposals & review
– API discussion
• Closing remarks
• Action items
NOTE: If you are on the public mail list but have not yet joined the Community Group but would like to attend the meeting you may certainly do so. However, if you are planning on making a contribution you will need to join the CG and make those contributions on the mail list.
Here is the link to the current CG participants and a link to join:
http://www.w3.org/community/orca/participants
Looking forward to seeing you!
/Erik
Live Blogging – IETF 88 – MTI Video Codecs
Chair: Taking the discussion back to the list.
—
Harold: We are witnessing a massive abuse of IETF policies. We have spent months on this.
—
Long line at the mic now
—
Consensus Call:
NEITHER CODEC WAS SELECTED
—
Consensus Call:
VP8 – about 30% of the room
Jabber: 30 for VP8 and 10 for 264
—
Consensus Call:
H.264 – about half the room
—
Chair / Ted Hardie:
Regarding the consensus call, raise your hand for either or both but not neither. This is not a call but simply calrification
—
Chair / Cullen: Agreed, hugs coming your way.
—
Martin: Keep in mind there are some that can’t get up and talk about that.
—
Chair / Cullen: We want to ask if you can’t live with either one of these codecs please get to the mic.
—
Tim Terryberry: Re: JR we need a royalty bearing codec if webrtc is to take off. I don’t think I need to tell the people in this room how excited everyone is about video in a browser without a plugin, ll of those are VP8.
—
Justin ? : Risk and Trust. Free codecs sounds good but today that’s not a reality. One of the advantages of going through an SVDO process is that the members must declare IPR, free codecs do not go through that. VP8 is not a free and the wind codec, it’s owned by Google. Google controls all of what VP8 is, can they be trusted. Who has implemented VP8 from the spec, not source.
—
?? – Technology is for people. The decision is for what we have today, not yesterday. Google has done a great job.
—
Harold Alvestrand: If people think that this announcement from Cisco of “later to be provided code” then I have real issues with the IETF process. Sooner or later we should find a way forward to rely on un-encumbered patent- less codecs, and if not now, then when?
—
Eric Rescorla: Mozilla intends to support 264 and VP8. We intend to support 264 via Cisco’s code/plugin on desktop. We will try hard to use the hw codecs since that works better on mobile. The user experience, during the install the codec will be installed (part of the install process). VP8 will be shipped with both mobile and desktop.
—
Bernard Aboba: It’s ok JR we do love you, hugs later.
—
Blackberry ?: Like the idea we would have a track towards better quality. The license is a big issue. VP8 is not a specification in the MPEG LA, but since it’s not there we have no mitigation there so we can’t make VP8 the MTI.
—
Randell Jesup: Those who are not making a browser but instead a server like asterisk or the like, their users would also have to download this plugin codec as well. It’s unclear if this would fall into the personal non-commercial use category. IT is not going to like this either, dealing with plugin codecs will make their lives potentially rather difficult.
—
JR: Arguing that we must choose a MTI codec or they can’t ship
—
Robin Raymond: I think it’s great that this new 264 codec is out there but if we make it mandatory the little guys lose. Mobile can’t download a binary, it must be part of the app before deployed. If you need H.264 you can add it if you need it but don’t force that royalty bearing codecs on all of us.
—
JR: Users don’t need to get plugins, apps do that.
—
Dean Willis: I don’t build browsers. For the last 7 years I have made my career on IPR consulting. If we were to pick 264 as MTI and since Cisco is not part the MPEG LA there seems to be risk there. Seems to me no choice works as well.
—
Roman Mahy: The most compelling items were the embedded platforms. My experience it was at one point very hard to find hw accelerated encoding, in the past.
—
Peter Thatcher: We turned on transcoding for a well known chat service and no one noticed. We are better off allowing the market to decide as Martin indicated months ago.
—
Justin Uberti: Regarding Adam’s comments regarding someone recording calls does not the understand the current laws. If you want to ship h.264 you can, no one is stopping you but not as the MTI codec.
—
John Peterson: This Wg has made plenty of decisions re: interop and we have saddled this WG with SIP /OA, but I think we should go with H.264
—
Roberto ?: The bias seems to be present, that larger companies have an easier time sending people here. If you choose to make 264 the MTI you are cutting out the small guys. I think the best option is to choose neither.
—
Matt ?: There are plenty of lawsuits against 264 so to say there is no risk with 264 that is simply not true. External plugins are not cool.
—
Ted Hardie (independent) : I offered JR a hug as he seemed to feel the free 264 effort was not appreciated. One of things we were trying to avoid is a plugin scenario and this (other things were added) is the reason we can’t invoke 264 as the MTI video codec. Royalties will push away numerous developers, big and small. Since 264 is now free (not free from royalty), we can add that codec as a non-mti codec.
—
JR: Transcoding degrades quality.
—
Martin Thompson: Let’s stop messing about with semantics, 264 is clearly the correct choice here so let’s get on with it.
—
Chair / Cullen Response: That was put to the list months ago and no one came forth with a proposal so that is not on the table today.
—
Jeremy ?: We could also consider both codecs.
—
Jean ?: Calling Nokia to the mic to clarify why there is a patent claim on VP8 and not on 264.
—
Peter Thatcher: Seems there are 2 broad categories, H.264 is better and the patent argument. The first is simply perspective and the second the patent being mentioned with Nokia is not resolved and if we are making a decision to implement 264 maybe those making that decision should wait until that is resolved.
—
Justin Uberti: Interop is misunderstood. Transcoding is cheap so that does not hold in the commercial world. VP8 is shipping in plenty of endpoints. Hardware Codecs are quite a ways off, there is LOTS of works that needs to be done here.
—
Monty Montgomery: If we go down this 264 path we are staking our future on a binary law environment.
—
Harold: To Cisco, please publish your findings
Cisco: Certainly
—-
Open Mic
—
JR / Cisco Conclusion
—
JR Arguing Risk Analysis
—
JR Arguing Risk Assessment
—
JR Arguing Distribution
—
JR arguing the results in Germany (re: Nokia VP8 patent being put down in Germany) may or may not be a consideration
—
JR arguing that VP8 is a target for patent trolls
—
JR arguing patent risk
—
Distribution
—
JR arguing both codecs perform nearly the same so let’s get past that
—
Justin asking, which of these represent (slide below) actual Real-time encoode/decode
Cisco response: much smaller percentage
—
H.264 vs VP8 Deployment & Standard
—
H.264 Shipping Date
—
Jonathan Rosenberg on H.264 for Cisco is at the mic
—- that was fast, thanks Harold! —-
Harold is at the mic..
NOTE: This post may not be entirely accurate. I am not the fastest typist in the world and I ad-lib when I can to get the general gist in the post.
