Archive | Standards RSS for this section

WebRTC in 2017

The road to the promised land.

For more than 6 years, we have been working on and looking forward to a simpler way to build RTC (Real Time Communications) applications on the web. In order for this technology to truly show its value, the major browser vendors needed to show up.

Now, it’s a reality!

Screen Shot 2017-06-12 at 5.07.26 PM

macOS SierraLeft: Safari Preview 32 (Safari 11.0, WebKit 12604.1.23.0.4) using H.264  Right: Chrome Version 58.0.3029.110 (64-bit). https://webrtc.github.io/samples/ using H.264

Mobile, mobile, mobile.

Now that Apple has joined the party in earnest, does the technology have the coverage required in order for developers to make good use of WebRTC on mobile devices? Let’s find out.

Until now, in order for WebRTC to work on iOS, we were relegated to wrapping WebRTC code in Objective-C and Swift, in our native iOS apps. Basically, we had to take the Chrome code and build an app that was sent to the app store for approval and wait in line, like all the other chumps (yours truly included). Conversely, on Android we could run much of that same code from our desktop Chrome apps, on the Android device as well, within reason of course.

Now that Safari and Chrome are shipping compatible WebRTC on mobile, we get to reuse the same code, right!? Well, mostly, they are different code bases, after all.

A word about hardware acceleration.

If ubiquitous mobile video is to take off, the battery life of the device has to last more than the length of the 10 minute video call (ok, I am exaggerating a bit, but I think you get the point) and the performance needs to be at least adequate enough to distinguish facial features. My bar is set a little higher, baby steps for now.

Without h/w acceleration the CPU is likely working too hard to encode the local video and decode the inbound video + service the other processes required at the same time. That really means there needs to be hardware onboard the device dedicated to video coding. That in turn means H.264, since there are very few vendors that offer VP8 or VP9 h/w acceleration.

Question: Does this mean that mobile apps written with VP8 will not be able to deliver decent mobile video conferencing?

Answer: No, not at all, but they will likely not be as performant as those taking advantage of hardware acceleration.

Suffice to say that SVC (Scalable Video Coding) usage would be another reason why we need h/w acceleration, but that’s for another day.

Who’s using what?

The majority of desktop and mobile WebRTC apps written today, are using VP8 for video.

Since Apple and Microsoft both use H.264 and Google uses VP8 and H.264 (recently shipped Open H.264 – on the desktop and mobile). Also, many of the Enterprise RTC developers are already on that H.264 bandwagon.

Question: If Apple and Microsoft devices ship with H.264, what is the case with Google Chrome on desktops and android, are they preferencing VP8?

Answer: Chrome for desktop and android now have H.264 native. Many of the Android devices that ship today all have H.264 hardware acceleration onboard. In order to understand which units have H.264 and hardware acceleration, you can run use the Android APIs to pull a list of available codecs, but in the case of WebRTC, you will only get H.264 in Android WebRTC if there is a h/w encoder on the device.

Is H.264 the answer for WebRTC video?

Here is a recent test:
Host 1 – (before joining):
macOS Sierra, Macbook, Safari (Technology Preview 32)

Screen Shot 2017-06-13 at 1.17.11 PM

Host 2 (after joining):
Android 7, Samsung 7, Chrome 55

chrome-android

setRemoteDescription OperationError: Failed to set remote video description and params.     Likely because Safari is not seeing H.264 on Android.

Host 1 (after joining):

Screen Shot 2017-06-13 at 1.39.57 PM

According to the Chrome Status page, Chrome for Android should have H.264. So why is the session barfing when trying to set up video? The logs do not lie…

Safari – offer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:99 H264/90000

Chrome on android – answer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:97 rtx/90000

Err, huh? No H.264 in reply?
So, I updated to latest Chrome on android (58) and tried again…

Screen Shot 2017-06-13 at 5.26.44 PM
et voilà!!

Next topic, paying the man!

Shipping your product with H.264 enabled, means you may potentially need to deal with the MPEG-LA royalty police for H.264 royalties, but there are some grey areas.

In the case of Apple and Microsoft, where H.264 royalties are already being paid for by the parent vendor, the WebRTC developer is riding on the coattails of papa bear, at least in theory.

Cisco’s generous OpenH.264 offer means that those using this binary module, can do so at potentially no cost:

We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.

Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I’d otherwise have to pay?

A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user’s computer or device. Cisco will not be liable for any licensing fees incurred by other parties.

That seems to mean (I am no lawyer) every developer shipping WebRTC apps supporting Open H.264 binary module, get a free ride. Those using some other binary, or shipping the above source code for that module, could be on the hook for those royalties. That said, since there are royalties being paid by parent vendors where devices are shipping H.264 anyways, developers may not get hassled regardless.

Summary:

So what did we learn here?

  • Apple has joined the party, now we have a full complement of browser vendors!
  • If you want to leverage WebRTC video to deliver a ubiquitous mobile and desktop experience for your users, you should likely consider including both H.264 and VP8.
  • VP8 is (still) free and powers most of the WebRTC video out there today.
  • You can make use of the Open H.264 project and get a free H.264 ride, albeit baseline AVC.
  • WebRTC on Android does not support software encoding of H.264, so unless there is local hardware acceleration, H.264 will not be in the offer.
  • H.264 is not fully enabled (or buggy) in Chrome 55 (I was using it on Samsung S7 Edge (Android 7), but it does work with Chrome 58.
  • WebRTC is not DOA!
  • SDP still sucks and ORTC can’t come soon enough!!

The W3C and IETF are also closing in on shipping WebRTC as a web standard, here’s a great update from Google on that as well. Latest W3C WebRTC editor’s draft, latest charter.

As a side note, it would be interesting to see something like this open sourced; VP8 / H.264 conversion without transcoding, if only to service the existing desktop apps currently running VP8 <-> mobile H.264. It would likely overwhelm the mobile device, but it would be cool if it worked!

Disclaimer: The views expressed by me are mine alone and do not necessarily represent the views or opinions of my employer.

WebRTC Ships in MacOS and iOS 11

Update:

Looks like VP8 is not there after all, bummer. More political jostling afoot, which sucks for the development community.

This is a big deal, to have Apple / Safari onboard is really the final major obstacle in the adoption of this awesome standard.

More info (thanks Marc Abrams !!)…
Based on the beta for macOS High Sierra – that was made available yesterday…
https://cl.ly/3q0p1O3…­
– Test samples: webrtc.github.io/samples/ (It passed most of the tests)
– Video codec support is VP8 and H.264 (I have not seen a test that shows H.265 or HEVC but I know it’s there)
– Audio codec support is Opus, ISAC16, G.722 and PCMU
– Basic datachannel support is there but none of the tests seem to work

 

AWESOME!!! This took a bit longer that many of us were expecting, but hey better late than never!

Screen Shot 2017-06-06 at 4.45.16 PM

PulverHWC – How We Communicate

Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.

Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.

Hope to see you there!

Erik


The Keys to the Communications Universe

Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.

Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.

There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.

Thank you!

Warm hugs, Jeff

W3C ORTC CG – Editors Draft Update – May 4

ORTC CG Editors Draft Update

http://ortc.org/wp-content/uploads/2016/05/ortc.html#change-log*

B.1 Changes since 01 March 2016

  1. Added the gather() method, as noted in: Issue 165
  2. Removed “public” from RTCIceGatherPolicy, as noted in: Issue 224
  3. Removed the minQuality attribute, as noted in: Issue 351
  4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
  5. Provided additional information on ICE candidate errors, as noted in: Issue 402
  6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
  7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
  8. Clarified payloadType uniqueness, as noted in: Issue 405
  9. Updated the list of header extensions, as noted in: Issue 409
  10. Added “goog-remb” to the list of feedback mechanisms, as noted in: Issue 410
  11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
  12. Clarified send() restrictions on kind, as noted in: Issue 414
  13. Added getAlgorithm() method, as noted in: Issue 427
  14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
  15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
  16. Clarified support for the “direction” parameter, as noted in: Issue 442
  17. Clarified the apt capability of the “red” codec, as noted in: Issue 444
  18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
  19. Clarified firing of onssrcconflict event, as noted in: Issue 448
  20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
  21. Updated references, as noted in: Issue 457
  22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
  23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
  24. Corrected use of enums in the examples, noted in: Issue 466
  25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
  26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
  27. Changed hostCandidate type, as noted in: Issue 474
  28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
  29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
  30. Updated description of RTCIceTransport object, as noted in: Issue 477
  31. Updated description of relatedPort, as noted in: Issue 484
  32. Updated description of RTCIceParameters, as noted in: Issue 485
  33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
  34. Provided a reference to error.message, as noted in: Issue 495
  35. Clarified RTCRtpReceiver description, as noted in: Issue 496
  36. Clarified default for clockRate attribute, as noted in: Issue 500
  37. Removed use of “null if unset”, as noted in: Issue 503
  38. Updated RTCSctpTransport constructor, as noted in: Issue 504
  39. Clarified behavior of getCapabilities(), as noted in: Issue 509
  40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

First Virtual W3C WebRTC Meeting

Last Thursday we had the first virtual w3c webrtc wg interim meeting. Once we sorted out a few technical details it went quite well!

Meeting Home Page:
https://www.w3.org/2011/04/webrtc/wiki/January_14_2016#Virtual_Interim

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/

Microsoft Edge ships ORTC API preview

Screen Shot 2015-09-18 at 4.50.33 PM

From Microsoft – http://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-now-available-in-microsoft-edge/

Our initial ORTC implementation includes the following components:

  1. ORTC API Support. Our primary focus right now is audio/video communications. We have implemented the following objects: IceGatherer, IceTransport, DtlsTransport, RtpSender, RtpReceiver, as well as the RTCStatsinterfaces that are not shown directly in the diagram.
  2. RTP/RTCP multiplexing is supported and is required for use with DtlsTransport. A/V multiplexing is also supported.
  3. STUN/TURN/ICE support. We support STUN (RFC 5389), TURN (RFC 5766) as well as ICE (RFC 5245). Within ICE, regular nomination is supported, with aggressive nomination partially supported (as a receiver). DTLS-SRTP (RFC 5764) is supported, based on DTLS 1.0 (RFC 4347).
  4. Codec support. For audio codecs, we support G.711, G.722, Opus and SILK. We also support Comfort Noise (CN) and DTMF according to the RTCWEB audio requirements. For video we currently support the H.264UC codec used by Skype services, supporting advanced features such as simulcast, scalable video coding and forward error correction. We’re working toward to enabling interoperable video with H.264.

More here..

%d bloggers like this: