• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
webrtcHacks

webrtcHacks

Guides and information for WebRTC developers

  • Home
  • About
    • Chad Hart
    • Philipp Hancke
  • Subscribe
  • Contact
  • Show Search
Hide Search

Standards Brief Victor Pascual · November 6, 2013

WebRTC Video Codec Debate Positions Infographic

With all the drama of the video codec debate ramping up for a Mandatory To Implement (MTI) decision (previously discussed here and here), hopefully it will be a minor footnote in the history of the WebRTC very soon.  If you had to summarize the possible outcomes, interested stakeholders, and sentiments in one picture, here is what the webrtcHacks team thinks it might look like:

WebRTC Video Codec Debate Positions in a Nutshell
With lots of assumptions and generalizations, this is an overview of the possible outcomes and interested entities in the WebRTC MTI video codec debate.

A few notes explaining the diagram- Sentiments of “happy with it”, “fine, I’ll live with it”, or “this crushes all my hopes and dreams” in this case centers mostly around the desire for interoperability.  The case of “VP8 & H.246”, it assumes that all the browser implementations end up fully supporting both codecs, but that they are completely negotiable (and possibly constrainable) on a session-by-session basis for each application using them.  This way non-browser implementations could implement VP8 or H.264 depending on their preference, and be guaranteed interoperability.

If you missed the discussion until now (really?), here is a summary of the major perspectives:

  • The four major browser vendors have the install based and resources to fuel the soon-to-be billions of WebRTC implementations.
  • The non/embedded-browser entities really want their non-browser systems and services (e.g. conferencing platforms, endpoints, media servers, etc.) to work with them. The large established CSPs and vendors, and enterprise IT have massive investments in stuff that already uses H.264, and they don’t want that minimized if it becomes non-interoperable with the web.
  • The many industry challengers can’t/won’t pay potential costs for H.264 and want to be sure they can create non-browser implementations of services and systems using a free and open codec like VP8, thatwill interoperate with the web.
  • In all cases, this assumes that the chosen video codecs can be delivered to the browser in a way that is transparent, free, and un-obtrusive to web end users first, and  the web developers second.

 

Disclaimer:  Clearly it’s a complex debate, and this is an attempt to simplify it based on our views.  The very broad categories of the entities in the debate, and the representation of their opinions/sentiments are based on our research including industry discussions, press releases, and emails on the IETF RTCWeb mailing list.  As always, were happy accept comments/corrections.

Also, there is a survey posted here…feel free to weigh in if you can’t do it in person in Vancouver!  Here’s hoping this will be over soon, and we’ll all get back to  WebRTC less dramatic technical challenges.

Please feel free to redistribute this image.

 

 

Standards Brief

Related Posts

  • Chrome’s WebRTC VP9 SVC Layer Cake: Sergio Garcia Murillo & Gustavo GarciaChrome’s WebRTC VP9 SVC Layer Cake: Sergio Garcia Murillo & Gustavo Garcia
  • Optimizing video quality using Simulcast (Oscar Divorra)Optimizing video quality using Simulcast (Oscar Divorra)
  • The Big Churn – learning from real usage stats (Lasse Lumiaho and Varun Singh)The Big Churn – learning from real usage stats (Lasse Lumiaho and Varun Singh)
  • OMG WebRTC is tracking me! Or is it?OMG WebRTC is tracking me! Or is it?

RSS Feed

Reader Interactions

Comments

  1. Lawrence Byrd says

    November 8, 2013 at 2:54 pm

    This is great, Victor! The most understandable perspective on the battle I have yet seen. Thanks.

    Reply
    • Victor Pascual says

      November 9, 2013 at 3:15 am

      Thanks Lawrence — credits to my colleagues Reid and Chad, this is a team effort 😉

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • Sponsored. Become a webtcHacks sponsor

Email Subscription

Subscribe to our mailing list

* indicates required

Twittering

Tweets by @webRTChacks
webrtcHacksguides and information for WebRTC developers

Footer

SITE

  • Post List
  • About
  • Contact

Categories

  • Guide
  • Other
  • Reverse-Engineering
  • Standards
  • Technology

Tags

apple Blackbox Exploration Brief camera Chrome code computer vision DataChannel debug e2ee Edge extension gateway getUserMedia ICE ims insertable streams ios ip leakage janus jitsi MCU Microsoft NAT opensource Opus ORTC Promo Q&A raspberry pi Safari SDES SDP sfu signaling simulcast standards TURN video vp8 w3c Walkthrough Web Audio webrtc-internals wireshark

Follow

  • Twitter
  • YouTube
  • GitHub
  • RSS

webrtcHacks · copyright © 2023