John Bartlett has started to write about SVC here at NoJitter; his initial post looks at the basic characteristic of SVC. I think that it has been a long time coming and I'm glad SVC is getting such high profile. But I had to correct something that may be inferred from his post and may even make the whole bottom line different (and even wrong).In his post John mentions that, by using SVC, MCUs will become a lot less complex, easily implemented and scaled.
While that sounds real good on paper, the reality is a lot more complicated than that.
We Live in a Legacy World Doing SIP? Thinking about XMPP and Jingle? Guess what--most of the video conferencing world still uses H.323.
Same goes for video coding technologies. While H.264/SVC is the future, most of the equipment out there still does H.264/AVC (or even H.263--god forbid). This means that an MCU in today's world is going to work very hard, harder than usual, with the introduction of H.264/SVC endpoints, to connect these to all the "legacy" endpoints that don't support it.
The MCU will have a ball in such a call, working point-to-point with each endpoint, aggregating the video streams and then sending out to each endpoint exactly what it is capable of receiving: with some endpoints it will work in H.263, with others with H.264/AVC and those with SVC will get SVC streams.
MCU in an SVC world
Oh, and as SVC for video conferencing hasn't been standardized yet, the MCU may even have to bridge between different "flavors" of SVC.
So no, now MCUs become even more complex instead of less.
Why Use H.264/SVC in an MCU? So you might now be thinking what DO we gain from H264/SVC in an MCU world? If it adds more headaches just because we need to deal with a heterogeneous world, why not just dump SVC and be done with it?
Well, there are two main benefits that make it worthwhile:
1. Large meetings--Using SVC can optimize the MCU's (the encoder) work when dealing with a large number of participants, even when not all are SVC-based clients.
2. Network resiliency--SVC can be used, not only for scaling, but for resiliency against packet losses that might occur. This is done by rearranging the video stream a bit on the encoder side, and then adding some error correction on top, utilizing the layered structure of the SVC stream. This is one of the main advantages of SVC today, as far as I can see. You can read John's second post on SVC, which covers this benefit rather nicely.
SVC is a great piece of technology, as I'm sure John will continue to explain--We're actively promoting it and using it. It is a great addition to any video infrastructure, but by no means does it simplify the development of MCUs. Not yet, at least.
