Archive | Object RTC RSS for this section

ORTC CG Meeting – 5

A few more changes to be made before we call for implementations, very, very close now. Should happen in next couple of weeks with new Editor’s draft.

Google Chrome 38-39 to ship with ORTC / WebRTC 1.1 APIs

For those who missed it, Chrome 38-39 looks like it will be shipping with ORTC 1.1 RTPSender / Receiver APIs as announced by Justin Uberti at Google I/O 2014. This really should not come as any surprise as RTPSender / Receiver APIs are now on track for WebRTC 1.0 integration as well, as per the last W3C WebRTC WG Interim meeting.

ORTC in Chrome 38-39

 

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.

ORTC CG Meeting Video – Hookflash, Jitsi.org, Microsoft, Google and others.

Very productive CG call today, here is the entire 1 hour and 40 minutes. Plenty of great feedback coming from Bernard Aboba (Microsoft), Shijun Sun (Microsoft), Justin Uberti (Google), Emil Ivov (Jitsi.org) and Robin Raymond (Hookflash).

Looks like we are shooting for a Public Draft (with sample code) by end of June, we’ll see if that is achievable (there are quite a few question marks remaining) but at least we have a target.

If you are interested in joining the ORTC Community Group, you can do that here.

Read More…

ORTC Sender / Receiver Capabilities Proposal is a big deal for SVC

ORTC Logo

There is a some interesting activity regarding Sender / Receivers on both the WebRTC WG and the ORTC CG.  Robin Raymond of Hookflash (ORTC CG Editor and Chair), submitted this beauty over an hour ago. To me, this is where we begin to see some real benefits offered by an Object model that is not encumbered by SDP O/A.

Hint: SVC (Scalable Video Coding or Scalable Video Codec) becomes the norm, not the exception.

From Robin’s proposal…

Introduction After attempting to write out some use cases using the existing RTCRtpSender and RTCRtpReceiver objects and parameters for ORTC, some issues were discovered. Specifically, the application developer would need to have a fair amount of knowledge on exactly how to tweak low level parameters for anything beyond very simple use cases. For example, setting up an SVC (Scalable Video Codec) would have required knowing about what codecs support SVC, how the layering is setup for particular codecs, and finally setting up specific geometric (or temporal) attributes and layering relationship details by an application developer.

Robin also includes some great SVC use cases..

Alice wants to use a SVC (Scalable Video Codec) to send to Bob

This is for illustration purposes only. Typical benefits of SVC are
greater in conference scenarios rather than traditional point to point
scenarios. However, this scenario can presume that an intermedia
conferencing bridge would be between Alice and Bob.

Current Parameter Based API

Step 1: (Alice)

var senderCaps = RTCRtpSender.getCapabilities();

mySignal(senderCaps);

Step 2: (Bob)

var senderCaps = mysignal();

var receiverCaps = RTPRtcReceiver.getCapabilities();

Read the rest here…

H.264 has won the WebRTC codec debate

H.264 AVC for WebRTC
A few things have happened that lead me to believe that H.264 has already won the WebRTC codec debate, regardless of what was not decided in the IETF RTCWEB or W3C WGs…

 

– Cisco delivers Open Source H.264 Codec via OpenH264.org

– Google and Cisco demonstrate H.264 interop in Chrome

– WebRTC Source Code for H.264 implementation surfaces in the WebRTC Developer mail list

So it looks like Chrome will end up supporting H.264 = they will support both VP8 & 264

Mozilla / Firefox already said they will support both.

Apple seems to be getting more involved, my guess is that they will announce some level of WebRTC support for Safari at WWDC. If they do, they will also favor H.264.

Since ORTC will be compatible with WebRTC to some degree,  IE modern APIs group has indicated that ORTC is “under consideration”. Microsoft also seems to favor H.264.

That covers all the major browsers.

It feels like the MTI Video codec issue is a non-issue.

ORTC, WebRTC & Doohickeys

The ORTC CG is making great progress on many fronts and it looks like the conversation around RTPSenders & Receivers (formerly known as Doohickeys) is taking more shape in the WebRTC WG. They even have a name there now: RTCRTPSenders / Receivers. The WebRTC WG teleconference call today was far less controversial than I am used to, it felt like everyone is trying harder to get things done.

I am not convinced we need Constraints at all in 1.0, by the rumblings on the calls it seems as though I am not alone. You can see that conversation taking shape in the Working Group here:

http://lists.w3.org/Archives/Public/public-webrtc/2014Apr/

Here is a decent summary on the recent ORTC API update.

ORTC API – Editors Draft Update

ORTC - Object RTC

Current editor’s draft of the ORTC API has been published: http://ortc.org/wp-content/uploads/2014/04/ortc.html

The next ORTC CG meeting is scheduled for April 17, 2014 at 10am Pacific. For more information on the W3C ORTC Community Group meeting you will need to join the Community Group here.

 

W3C ORCA CG is now ORTC CG

We have officially changed the name and URLs for the ORTC CG (formally ORCA CG).

The old URLs will be redirected to the new ORTC CG: http://www.w3.org/community/ortc/

If you are an existing member of the ORCA CG please register at the new ORTC CG, or if you wish to become a member please register here.

Here is the notice that went out to existing members…

Hello ORCA Community Group members.

We are changing the CG name from ORCA to ORTC as requested by some of our members and other W3C members for various reasons discussed in that last CG meeting. Minutes can be found here: http://ortc.org/ortc-cg-meetings/

After discussing this with the W3C we had the choice to a.) change the name to ORTC but keep the current ORCA URI or b.) set up an entirely new CG. Since we didn’t want any confusion (ORTC CG name with a ORCA URI) we opted for the second option.

We have been told that a second legal review should not be necessary by your sponsoring organization since the new CG is simply replacing the existing CG.

Here is what that means to you as a member of ORCA:

  • You will need to join the new CG: http://www.w3.org/community/ortc/
  • You will need to join the public mail list.
  • Signups for the ORCA group will soon be suspended
  • Emails sent to the ORCA mail lists will not go through, you will need to use the new lists for new postings. Emails sent to the orca lists will return a message pointing to the new lists at ORTC CG.
  • ORCA mail lists will live on and will be referenced for historical purposes.
  • All Community Groups fall under the guidelines in the W3C Community Contributor License Agreement (CLA), so nothing changes there.

Soon we hope to publish a Public Working Draft of the API so that we can start implementing the API.  Some of that work has already begun:https://github.com/openpeer/ortc-lib

If you have any questions about the name change please forward those to erik@hookflash.com

Thank you all for you continued support!

%d bloggers like this: