XvMC 2.0?

[Kendall Bennett]

Torgeir Veimo <torgeir at pobox.com> wrote:

> On Tue, 2005-02-01 at 10:06 -0800, Kendall Bennett wrote:
> 
> > Finally we could consider whether we want to add network transparency to 
> > the XvMC API,
> 
> Hav you done any measurements on the bandwidth required for normal DVD
> playback when XvMC is fully utilized?

No, not yet. 

But the bandwidth requirements are relatively easy to compute. Each macro 
block is 16x16 pixels in size and is represented by one XvMCMacroBlock 
structure, which is 36 bytes in size. Each macro block has optionally up 
to 6 8x8 16-bit blocks (128 bytes each), for a maximum of 768 bytes per 
macro block. Note that in many cases of the P and B frames the macro 
blocks are not necessarily used, so the bit mask is used to avoid sending 
the block at all. So for a DVD video at 720x480 resolution, there are a 
total of 45x30 macro blocks, or 1350 macro blocks for a single frame in 
the worst case. So the worst case scenario would be that we would need to 
transmit 1350 * (768 + 36) = 1085400 bytes per frame of DVD quality 
video.

The final frame of YUV12 video at 720x480 resolution will take up (720 * 
480 * 1.5) or 518400 bytes when it is uncompressed. 

So clearly in the worst case it will actually be nearly twice as 
expensive to send the undecoded macro block data over the wire to the 
target machine as it would be to send just the raw YUV stream data.

However in practice the worst case will not happen very often, and 
decompessing the video stream is computationally expensive. On average I 
imagine the network bandwidth would come out about the same, but the CPU 
overhead of decompressing the video stream would be a lot lower for the 
server machine if the client is handling the motion compensation in 
hardware.

So maybe it is worth it, maybe it isn't. One could argue that CPU power 
is cheap these days and you can easily do DVD quality decoding on a 1Ghz 
Pentium machine in software, so modern hardware usually has no problem 
with the software decoding side. 

But if you are using thin clients, maybe it would be worth it for the CPU 
savings on the server side.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~