[x264-devel] H264.SVC

[Aaron Drew]

Hi Jason,

Firstly, thanks for the detailed reply.


> 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.
>

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?


> 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.
>

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.


> 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:
>

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.

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.
>

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.

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.

Thanks for your reply. Its good to hear so directly where the x264 teams
stands on SVC.

- Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100113/ca7cec9b/attachment-0001.htm>