Keeping things simple requires complicated effort

WebRTC MTI Video Codec: More is Less

Webinar Poll Results Different From My Opinion

Last week I held the second Webinar in the series of WebRTC Webinars for Upperside Conferences. This time it was with Victor Pascual Avila who gave an update about standards. We had 2 live sessions, one in the morning EMEA time and second in the morning US time.

In case you missed it, slides are available as well as the recording.

Keeping things simple requires complicated effortPrior to the Webinar I wrote about the areas WebRTC standards cover and more importantly, why it is good WebRTC defines only the minimal must requirements, As an opening to the Webinar, I presented that diagram and spoke about the “Less is More” advantage in WebRTC standards.

In a nutshell, we want any WebRTC application to run in any WebRTC enabled browser, thus, W3C standardization work is important.

Additionally, we want one WebRTC implementation to work with any other WebRTC implementation and therefore definition of transport, security and media codecs are important, AKA, work done in IETF.

Since WebRTC is built with Web in mind and for the Web, similar to other Web technologies, the way the browser communicates with the server, structures data exchanged and acts upon that data is in the hands of the application.

This is how innovation thrusts.

Poll Question: What should be the mandatory video codec in WebRTC?

After Victor spoke about the different point of views of vendors and segments on the mandatory to implement (MTI) video codec in WebRTC we presented this poll question. Options to choose from were:

  • H.264/H.265
  • VP8/VP9
  • Both should be mandatory
  • There should be no mandatory video codec
  • Don’t care, just make up your mind…PLEASE

To my great surprise, in both sessions, the majority (around 40%) selected option 3.

The need for a mandatory video codec

The preferred option for connecting a session is with media flowing directly between the 2 browsers. In some cases, due to FW/NAT complexities, there is a need for media to go through a TURN server. In both of these options media flows securely between the browsers and even when there is a need for a forwarding server in-between, it doesn’t (and can’t) touch the media, decrypt it or transcode it.

Achieving this requires both browsers to support the same codec.

If they don’t, a transcoding server will need to be placed in the middle, be part of the communication breaking privacy and overloading servers with CPU intensive transcoding and media decrypt/encrypt tasks.

Considerations for selecting the mandatory video codec

There are a few parameters to take into consideration when selecting the MTI codec:

  • Quality
  • HW support
  • License
  • Royalties
  • Porting
  • Future codecs

 

Quality

All in the eyes of the beholder there are different comparisons and opinions depending to a large extent on what camp/company one is part of.

In my eyes, both options are of good enough quality. I don’t see a significant enough difference that would make the decision lean towards one option over the other as long as comparison is apples to apples (VP8 to H.264 and VP9 to H.265, network conditions and additional resiliency tools).

At the end of the day, the WebRTC MTI video codec decision is more of a business decision rather than a technical one.

HW support

H.264 is the standard codec used today for real-time communication. As a result of that, it is supported in many chipsets and mobile devices. This in turn allows for HW acceleration of the CPU intensive encoding and decoding tasks but that is right only for some of the devices and surely not for Apple devices.

On top of that, if an application wants to connect between a WebRTC client and a traditional video conferencing/UC client H.264 will probably be the codec found on the latter.

Having said that, chipset vendors are adding VP8 support as it is already supported by Imagination Technologies, the vendor providing this IPR to most of those vendors.

VP9 is also making its way to HW devices so this gap is about to be closed.

On the traditional video communications front, vendors are adding VP9 as an additional codec but that may take time.

License

Both H.264 and VP8 come with a permissive BSD license.

Google took care of that for VP8 and Cisco took on the challenge to open source H.264.

For the next generation codec, VP9 and H.265 it is a different story.

Google continues the same path of BSD open source for VP9. H.265 on the other hand comes as GNU GPL 2.0 or via a commercial license.

Royalties

Patents and royalty payments are one of the key questions to ask. As WebRTC lives in the world of the Web it is required to allow any developer to build his application without the need to worry about patent infringement. This includes not only applications that run in the browser but also mobile and other devices as they all need to interwork.

VP8 – Google made VP8 royalty free and handled all the patent issues. New issues may come-up once in a while but Google is committed and big enough to solve them. The royalty free “feature” comes with no strings attached, you can port the codec to any platform and still enjoy the Google umbrella.

H.264 – Cisco has also committed to free developers from the H.264 patent burden but the story here is different as in order to seek shelter under the Cisco umbrella you must use their binary package. This works well for browsers but what if I’m developing a mobile application and want the codec to be part of it? What if I want to port the codec to an embedded device and make changes to the codec? In these cases the developer will need to bear the royalties of H.264.

The work Cisco has done for freeing H.264 is well explained by Cullen Jennings in this video.

VP9 – Google has gone the same path.

H.265 – No indication for a similar arrangement by Cisco or others.

Porting

Since all 4 codecs come in some sort of open source license it is technically possible to take the code and port it yet licensing and royalty considerations apply as detailed above.

Future codecs

The decision between VP8 and H.264 will have a good chance to impact the decision of the future codec (VP9 or H.265) and therefore the considerations and differences detailed above (mainly in the licensing and royalty front) must be taken into consideration.

Mandating both is a bad option

So we agree there needs to be a decision.

We reviewed the different parameters to consider.

Why not go for both as the majority of the audience on the Webinar recommended?

There will be no need for a server in the middle to transcode and break privacy.

The 2 browsers will always be able to negotiate which codec to use and life will be great.

Not exactly!

Forcing the implementation of both H.264 and VP8, and in the future H.265 and VP9 increases complexity. WebRTC is open source and it will find its way into different types of devices, including proprietary embedded devices (think of a WebRTC enabled sensor, camera or medical device).

Moreover, licensing and royalty/patent issues will arise in some cases for H.264, and based on current status, in all cases for H.265.

Conclusion

Having H.264 added to the browsers can be a good thing. It will still be royalty free and will avoid transcoding and privacy breach needs in cases where connecting to traditional video communication systems. Additionally, it will eliminate the need to download it as some sort of plug-in in cases the application vendor decides to use it.

Having said that, adding H.264 voluntarily to the browser doesn’t mean H.264 needs to become mandatory.

My choice for MTI would be VP8/9 accompanied with a strong recommendation to add H.264/265 when possible and this is due to 2 simple reasons:

  • Licensing and royalty considerations are extremely important for allowing proliferation of WebRTC applications and services. This alone is a good enough reason
  • VP8/9 is becoming the video codec of the web and that is the natural environment of WebRTC
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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


1 + 3 =