15 comments on “Trick or Treat? Cisco’s OpenH264.org & What it Means in the WebRTC Video Battle

  1. In the scheme of things where it is probably impossible for MPEG LA to just give up and “go free” on behalf of their complex web of patent pool members, this seems to be he biggest move possible in opening up H.264 – so I think Cisco is to be congratulated regardless of any “is this enough” opinions! A bold step, it seems to me, and also perhaps a challenge to Apple (in particular) and Microsoft to make H.264 more open to WebRTC developers using their platform – it shouldn’t all be on Cisco, after all, to solve this dilemma of balancing integration with existing video systems versus open license-unencumbered codecs.

    • Thanks for the comment Lawrence. I agree some kind of positive statement from the MPEG LA on this would be ideal, but that will never work in the litigious patent system we have today. It is impossible to get assurances on anything. The next best thing is to get a major patent holder on your side to provide some cover – that is exactly what Open H.264 with Cisco does.

      I am eagerly waiting to see how this all plays out in Vancouver…

      • That’s exactly the point. If the MPEG LA doesn’t “free” H.264, then it is indeed not enough. Certainly not to impose a codec as MTI. I’ve said many times why I don’t think so, so I won’t state them again here. I’ve tried to raise my concerns on the RTCWEB ML as well,

        http://www.ietf.org/mail-archive/web/rtcweb/current/msg09318.html
        http://www.ietf.org/mail-archive/web/rtcweb/current/msg09335.html

        just to be ignored so far: I guess that I’ll either have to be hired by a big company, or wait for my tiny startup to be acquired from one, before my questions will be deemed worthy and answered. May take a while…

        • In this case (since it is RTC-Web), it seems “Manditory to Implement” really only applies to browser vendors, of which there are just a few. In other words, in reality there will be a relatively small number of “Implementations”, but much of the concerns are from non-browser implementors (big and small) that want to inter-operate with browsers. I assume you fall into this category Lorenzo? Do you think it might be feasible to have both VP8 and H.264 implemented in browsers, but allow constraints on them via the API? So that the actual services and applications could enforce what exactly they use, and the browser would inter-operate with non-browser implementations of either…and after all, it’s MTI, not “Manditory to Use”. I’m curious what your take on this approach would be.

          • Yes, that’s the category I fall in, and what a lot of other small developers and companies have been doing while H.264 advocates were busy doing something else.

            MTI applies to WebRTC-compliant applications in general. While it is of course much more important for browsers, it inevitably falls back on applications that do interact with them anyway. If H.264 is MTI and VP8 or whatever else is not, while Google and (maybe, I don’t know what to think about them anymore) Firefox will probably support VP8, Microsoft and Apple will definitely not deign other codecs of their consideration. Which means that your server side application that does streaming, conferencing, or whatever else may happen to generate content will need to talk H.264 if it wants to talk to ALL browsers. Just implementing VP8 would mean not support browsers that decided not to bother with it. If you’re only passing media through, instead, that’s not really an issue.

          • Reading your question again, maybe you were actually asking whether or not I’d be ok with both MTI. I guess I could be, as it would allow me to neglect H.264 entirely and still be confident that VP8 would be available: I don’t think that will ever happen, sadly, though.

          • Good point Lorenzo. If the browser folks (Appl, MS, Moz, Goog) don’t completely adhere to MTI (whether VP8, H.264, or both) and remain divided, then interoperablity is broke for everyone, even the “web”. Regardless, at least one of the browser vendors are going to have to implement a codec they don’t want, to achieve basic web-web interoperability. If one side or the other (or both) can budge on that…then it becomes about web-nonweb interop, and if you satisfy the larger establishments or the emergent ones (or both).

  2. Google: “Congratulations on the Cisco announcement – but we still prefer VP8” http://t.co/JJKkZrUmn9

    From: Harald Alvestrand
    To: “rtcweb at ietf.org”
    Date: Thu, 31 Oct 2013 19:47:31 +0100
    List-id: Real-Time Communication in WEB-browsers working group list
    We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.

    Google still believes that VP8 – a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today – is the best choice of a Mandatory to Implement video codec for the WebRTC effort.

    Harald (sending this from my Google address)

    • Well Google is absolutely right in the sense that a completely open, licence-unencumbered good quality video codec is ideal for the open web – which is VP8 becoming VP9 :)! And it is backed by a large vendor willing to fight ll the extraneous lawsuits against it. However the real world is full of vendors with IETF votes and sizable current and future H.264 (going to H.265) investments and lots of existing enterprise video systems much of which will want to be integrated with WebRTC endpoints, at least in near-term paid-for use-cases before WebRTC takes over the planet. Hence the exciting upcoming real-world “Mixed Media Arts” (MMA) fight in Vancouver! Get your tickets…

  3. Or should we just give up on mandatory-to-implement? Let’s play out the scenarios:

    1. W3C sticks with MTI, and no agreement emerges on the choice of video codec. Roll-out of WebRTC is slowed, until non-Google browser vendors go ahead, ignoring MTI, and bring out WebRTC implementations with only H.264. Mozilla straddles the fence and supports both codecs. Mobile SDK vendors vote with their feet and leverage native chipset support for H.264.

    2. W3C sticks with MTI, and VP8 is chosen. Enterprises wishing to deploy WebRTC have to stock up on VP8-to-H.264 transcoders, increasing cost and reducing the take-up of the technology.

    3. W3C sticks with MTI, and H.264 is chosen. This, I might suggest, would encourage Microsoft and Apple to come down off the fence and embrace WebRTC, despite Microsoft’s misgivings over the browser API.

    4. W3C sticks with MTI, and both codecs are chosen. Developers of new services can embrace VP8 and forget about royalty payments — until some non-member of MPEG-LA comes along asserting a patent claim. Some mobile SDK vendors may implement only H.264, but no big deal, because their apps are doubtless tied to legacy infrastructure in any case.

    5. MTI is waived, and the market chooses H.264.

    From where I stand (working for a Cisco partner, I should disclose) any solution that does not support H.264 would be a disappointment. While we do support video transcoding, that’s a cost that our customers have to bear.

    • “the objective of developing a standard where patent owners are prepared to grant a free-of-charge license (Type 1 license in ISO parlance) to an unrestricted number of applicants on a worldwide, non-discriminatory basis”

      That sounds promising, at least in the medium term….

Leave a Reply

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