[x264-devel] H264.SVC

[Jason Garrett-Glaser]

On Tue, Jan 12, 2010 at 8:18 AM, Aaron Drew <aarond10ster at gmail.com> wrote:
> Hi list,
> I work for a tech startup that is looking at making extensive use of video
> conferencing technology and we've recently been interested in the potential
> of H264.SVC. I realise that x264 lacks support for SVC right now but I am
> wondering what it would cost to sponsor the development of this and how long
> it would roughly take?
> I know this is a pretty open-ended question and there may be licensing as
> well as technical issues that make answering this quite hard but I'd like to
> know if there is anyone here that is both capable and willing to take
> something like this on and roughly how much would it likely cost in terms of
> both man-power and dollars.
> Feel free to contact me off list if that is more appropriate.
> Thanks,
> Aaron Drew

We're not very interested in SVC for a number of reasons--and equally,
I don't think it's very relevant for video conferencing at all.

Here's why.  First let's take the simplest example: a broadcast stream
with an HD and SD stream.  The HD stream is about 6 times the
resolution, and accordingly 6 times the bitrate.  So the SD stream
adds an extra 16% bitrate that wouldn't be there if we were using SVC.
 But SVC is not as efficient as normal H.264/AVC, with the loss
(AFAIK) being 10-15%.  So now the gain is only 1-6%, and thus we'd be
better off spending our time on something useful.

Now, for videoconferencing.  Here's the benefits I've heard about SVC
from time to time:

1) Error resilience: x264's Periodic Intra Refresh (coming in a few
weeks, ask me for the patch if you're interested) gives effective
resilience up to 20-25% packet loss, so this is irrelevant.
2) Saves bandwidth: only if you have a huge number of different target
clients who are only on subtly different connections and you insist on
giving them different video streams.  For example:

1 QCIF video, 1 SD video, 1 1080p video: SVC is worthless
1 1mbps 640x480 video, 1 2mbps 640x480 video, 1 3mbps 800x600 video, 1
4mbps 1024x768 video: SVC is useful.

Finally, I would say that _unless_ x264 supports SVC, it's a waste of
time for most applications, because the cost of using a low-end
encoder is simply too great.  x264 can now stream 800x600 video with
an end-to-end latency of under 10ms (encoding+decoding+buffer time,
not including transport); I haven't even seen a hardware
videoconferencing solution that can do that.

Dark Shikari