XvMC 2.0?
Kendall Bennett
KendallB at scitechsoft.com
Tue Feb 1 11:02:28 PST 2005
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! ~
More information about the xorg
mailing list