If anything, we will see more codecs we need to deal with.

If you are doing any backend video processing "stuff" then you know this already: This is no walk in the park.

For years I've been hearing MCU companies and other hosted video conferencing providers whine about (and then celebrate) the birth of yet another codec or system they need to integrate and interoperate with--you see, the more complex things are, the better positioned these vendors are in selling their products and services.

Things aren't going to change--if anything, we will see more codecs we need to deal with.

With WebRTC, the situation is unclear these days: Will we be using VP8? H.264? Something else and brand new the IETF started working on? People whine (myself included) about how we need to have a single mandatory video codec for WebRTC.

But do we?

A few weeks ago, Janko Roettgers wrote this post: To stream everywhere, Netflix encodes each movie 120 times.

120 times.

Each movie.

That's 120 different bitstreams per movie.

Just to be able to serve static video content.

This isn't just about the amount of storage. It is a matter of the operation required: The processing power, the workflow in place. Not an easy task.

Real-time video isn't any simpler either. So while WebRTC might reduce a lot of barriers for developers, there's a lot of smart backend to be done if a service wants to be as big or as successful as Netflix.

How WebRTC startups will deal with these backend challenges is going to be a large part of how they fare in the long run.