<div class="gmail_quote"><div>Hi Jason,</div><div><br></div><div>Firstly, thanks for the detailed reply. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
We're not very interested in SVC for a number of reasons--and equally,<br>
I don't think it's very relevant for video conferencing at all.<br>
<br>
Here's why. First let's take the simplest example: a broadcast stream<br>
with an HD and SD stream. The HD stream is about 6 times the<br>
resolution, and accordingly 6 times the bitrate. So the SD stream<br>
adds an extra 16% bitrate that wouldn't be there if we were using SVC.<br>
But SVC is not as efficient as normal H.264/AVC, with the loss<br>
(AFAIK) being 10-15%. So now the gain is only 1-6%, and thus we'd be<br>
better off spending our time on something useful.<br></blockquote><div><br></div><div>I hadn't read that before. Vendors producing SVC products have unsuprisingly neglected that sort of information. Is there a study or something I can read about this? </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Now, for videoconferencing. Here's the benefits I've heard about SVC<br>
from time to time:<br>
<br>
1) Error resilience: x264's Periodic Intra Refresh (coming in a few<br>
weeks, ask me for the patch if you're interested) gives effective<br>
resilience up to 20-25% packet loss, so this is irrelevant.<br></blockquote><div><br></div><div>20-25% error resilience is amazing. I am sceptical of some of the SVC claims of lower latency but I do see some additional merit related to packet loss that is specific to video conferencing situations. Given a base layer frame is much more likely to be smaller than the MTU of a typical connection (1480 bytes or there about) than an AVC frame, the impact of a lost UDP fragment is quite often lower in SVC than AVC. Even if the base layer requires multiple UDP packets, the advantage over AVC is that the loss of a single UDP fragment may not require discarding all the other fragments related to a given video frame. If the base layer is 15% of the actual video stream, if any of the other 85% of packets are dropped, the result is simply a fall back to base-layer quality rather than concealment.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2) Saves bandwidth: only if you have a huge number of different target<br>
clients who are only on subtly different connections and you insist on<br>
giving them different video streams. For example:<br></blockquote><div><br></div><div>Bandwidth management in multi-party situations is the main reason I have been looking at SVC. Take a 3 way conference between hypothetical users in Japan (20mbit downstream), the US (2mbit downstream) and outback Australia (256kbit downstream). I'm not looking to target multiple devices from QCIF to 1080p but my example, while contrived, is typical of today's Internet. I am on 50mbit fibre but I know people on 256kbit ADSL. Thats a factor of 200x the bandwidth. In 2 party conferences I agree with your sentiment entirely but in 3,4,5 party scenarios, "lowest-common-denominator" bit-rate seems quite disappointing. In this situation it would result in a 20x loss of potential bitrate and thus 20x loss in video quality for the US user over a solution that could target the available bandwidth of each user individually.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Finally, I would say that _unless_ x264 supports SVC, it's a waste of<br>
time for most applications, because the cost of using a low-end<br>
encoder is simply too great. x264 can now stream 800x600 video with<br>
an end-to-end latency of under 10ms (encoding+decoding+buffer time,<br>
not including transport); I haven't even seen a hardware<br>
videoconferencing solution that can do that.<br></blockquote><div><br></div><div>Agreed! In terms of latency, computational complexity, video quality and feature support, x264 is nothing short of fantastic. I applaud the work of yourself and the other developers. I actually wish I had the time to learn the ropes and join your ranks but I cant see that happening in the near future.</div>
<div><br></div><div>I see SVC's key benefit not in error resilience, bandwidth savings or device targeting but in its ability to concurrently provide streams for vastly different Internet conditions. The big secondary benefit being the average-case impact of packet loss on a stream but given 20-25% error resilience, this point is almost moot.</div>
<div><br></div><div>Thanks for your reply. Its good to hear so directly where the x264 teams stands on SVC.</div><div><br></div><div>- Aaron</div><div><br></div></div>