XvMC support

[smitty3268]

Details?

>
Out here in the real world, normal people don't buy a new computer
every three months to get the latest ueberphemon3++ 5.72 Ghz x16.
Full bitrate HD takes a lot more CPU than SD and computers in
the real world have trouble with it or can't do it at all.

I've heard several general complaints about this, but not a single hard number. I would have guessed a Pentium 3 would have enough juice for this - can you definitively state which CPU you have in your computer that isn't fast enough? If there are P4's that can't keep up that's one thing, but it's very different if it's just P2's that need to be upgraded. I don't really have an old computer lying around to test myself.

Personally, I would love XvMC support. But not at the expense of just about any other feature I can think of. It's got to be right at the very bottom of almost everyone's list. Hopefully someone can build some generic support into Gallium3D and we won't have to always keep waiting for specific drivers to get supported.

I'm sure it sucks to be among the few who need it, but as had been said: the specs are available and someone just has to step up and do the work. That's the beauty of open source

[rvdboom]

I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
There is another reason why having accelerated MPEG2 would be nice : professional HD codecs. Most of them (HDV, HDCam, XD-Cam) are still MPEG-2 based and it's quite nice to be able to work natively with them at full resolution. Blue Ray is still MPEG2 also, AFAIR.
But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?

[Kano]

I don't know if H264 and small fits in the same sentence But of course a generic solution using OpenCL for example would be very interesting.

[_txf_]

I don't know if H264 and small fits in the same sentence But of course a generic solution using OpenCL for example would be very interesting.

H264 is designed to be scalable and has several different profiles. AFAIK most flash based web videos are based upon h264, and it can offer a very good tradeoff on bitrate vs quality,especially in comparison to mpeg2 and mpeg4 asp.

[RealNC]

I don't know if H264 and small fits in the same sentence

Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers

Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.

[deneb]

I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.

If 1080p30 MPEG-2 and MPEG-4 ASP are problematic for your CPU, you are either dealing with very high bitrates (> 30 Mbps) or there may be something wrong with your player/decoder setup or the graphics driver.

Blue Ray is still MPEG2 also, AFAIR.

Blu-ray can carry MPEG-2, but also H.264 and VC-1. MPEG-2 is rarely used in new releases.

But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?

A generic API and decoder implementations would certainly be a good idea for the future. Today, the most efficient way to decode MPEG-2, H.264 and VC-1 is by using specialized hardware like AMD's UVD or NVIDIA's VP3. To use these kind of complete decoding solutions, we only need lightweight hardware-specific wrappers and a common API.

[deneb]

@ _txf_ and RealNC

I think Kano was referring to the size and complexity of a fully-featured H.264 decoder implementation, not encoded video.

[duby229]

Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers

Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.

I dont knwo if that is entirely accurate. Say you've got a 1:45 hour fourty five minute film and you want to keep the file at around 1500MB. Thats a fairly high bitrate. Even at that bitrate you can still see obvious blocking in dark areas. I have several films that are dark from start to finish, and they are blocky through out the entire film even, even at that bitrate.

[deneb]

Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.

[duby229]

Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.

These are my own encodes. I'm curious to hear more about VAQ, Is that somehow related to this patch?

http://files.x264.nl/x264_patches/force.php?file=./x264_aq_var.48.diff

If not then are you talking about Constant Quantizer? If so then what quantizer should I use to get near DVD quality?