News

Video: WebRTC Introduction (revisited)

[vimeo 47682405 w=500 h=281]

For those who missed this video the first time around, here is a great introduction to WebRTC (Real-time Communication on the web via HTML5 & JavaScript) from Cullen Jennings, Cisco Fellow & Co-chair of WebRTC & RTCWEB Working Groups in the IETF / W3C & advisor at Hookflash.

Cullen covers plenty of ground, focusing on the standards work surrounding this newly proposed standard that is WebRTC. A must watch for those interested in WebRTC. Sadly, there has been zero progress regarding MTI video codecs since this video was shot/uploaded 8 months ago. This MTI video codec issue really needs to be put to bed at the next IETF meeting in July.

H.264 for WebRTC MTI Codec

H.264 AVC for WebRTC

I have been supporting VP8 as the MTI codec in the WebRTC / RTCWEB WG, for various reasons including…

  • Royalty Free (drives innovation)
  • Open Source (Source code is optimized for RTC and readily available)
  • Supported by a rather large company (Google)

It seems some of us may be changing our minds (myself included), for various reasons, eg…

  • H.264 is prolific in RTC today. If we are to have interoperability with other endpoints out there we need 264.
  • Open Source. H.264 optimized source for ARM and X86 its coming, Cullen said so 🙂
  • Supported by many rather large companies (MPEG-LA for starters)
  • VP8 IPR is coming under heavy fire. Nokia being one firm that has boldly stated that they hold patents on VP8 and will enforce them, and apparently there is at least one more VP8 patent holder out there that is keeping rather quiet, which is rather disconcerting.
  • Since H.264 utilizes hardware acceleration, battery consumption on mobile devices should be lower as well.
  • Quality is arguably better in some cases, this can be somewhat subjective.

So where does this leave the innovators that need free software to create free software? Great question, and here are some potential answers…

  • If there is Open Source H.264 software out there that has been optimized for Real-time Communication (encoding and decoding in real-time) there are no “software” fees (excluding MPEG-LA), that is one less, rather large, obstacle.
  • MPEG-LA (last I looked) has stated that there are no patent fees associated with deployments under 100k endpoints. This is great for smaller deployments but larger deployments could still have a problem here?

Some are saying that the bulk of all mobile devices that could support video have a t least one license for H.264 already, so why then would there be another royalty for H.264 on that very same device? This is an interesting argument and one that may in fact provide the innovative developers with a leg up when it comes time to debate the issue with the MPEG-LA. That being said, most innovative developers I know want nothing to do with legal debates.

There is also another factor to consider, many of the MPEG-LA patent holders are behind WebRTC, so why then would they shoot themselves in the foot and hamper adoption of WebRTC by litigating those who adopt it? There has also been talk of creating a new H.264 license in the MPEG-LA related directly to WebRTC / RTCWEB, which would be free of royalties. Talk is cheap.

Those vendors who only run one codec today will have likely already chosen H.264 for their existing deployments and will likely vote 264 as the MTI codec. At the end of the day, the prudent vendors looking for the most coverage in WebRTC interoperability will support both H.264 and VP8, regardless of which codec is selected as MTI.

After weighing all the options it seems (to me at least) that H.264 is the better choice today, now we just need an open source (with a BSD or MTI license or the like) H.264 implementation that has been optimized for WebRTC.

I am interested in hearing what the developers out there think about this. What do you think? Should H.264 be the MTI (Mandatory to Implement) video codec for WebRTC?

Google forks Webkit in Blink, more WebRTC fragmentation?

WebKIT

 

As the go-to browser toolkit, WebKIT has been around for a long time and for the most part this open source project is owned by Apple with large contributions coming from Google ala Chrome.

In reference to WebRTC, Apple is really not saying or doing much around WebRTC (at least not publicly), so it should come as no surprise that Google might feel the need to drive innovation into their new Blink project. Obviously WebRTC is not the only motivating factor here but it seems likely that it played a part.

This is probably a good thing, Blink now provides an alternate solution to WebKIT and will seemingly move quicker with Google driving. It could also create fragmentation, which could (for some) be a bad thing. It also means there there is now another critical component of WebRTC under Google’s control, not saying that is bad, just sayin..

At any rate, it begs the question “Where the heck is Apple?” It would be nice to see this mobile market leader taking more of a leadership role in the development of WebRTC. They have been somewhat more vocal recently around the MTI video codec debate in the IETF but aside from that they have remained relatively silent. One thing seems certain, it will be up to Apple to maintain WebKIT now that Google is focusing on Blink.

Archives
Recent Comments
    Privacy Settings
    We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
    Youtube
    Consent to display content from Youtube
    Vimeo
    Consent to display content from Vimeo
    Google Maps
    Consent to display content from Google
    Spotify
    Consent to display content from Spotify
    Sound Cloud
    Consent to display content from Sound