VP8 Over VDPAU In Gallium3D Is Emeric's Target

[runeks]

This whole thing is kind of useless. VP8 on the internet is low-bitrate enough as to not need acceleration. H.264 would be much more important to have on top of Gallium.

I think the point Emeric made was that it just wouldn't be possible for him to make a H.264 decoder state tracker with the time he has.
So he would prefer ending up with a less usable but functional (VP8) decoder, rather than a more useful (H.264) but non-functional/incomplete decoder.
Implementing a full H.264 decoder in software took him six months last time he tried (1), and this time he has to learn about shader-based optimizations as well, so it would seem to be a bit too much work for one GSoC.

Also, he first started out his thread on the mailing list by proposing a generic implementation of various processes involved in video decoding, so that an arbitrary codec could just hook into these and accelerate decoding this way. But I'm not sure if he's left that idea as well:

The project would be to write a state tracker wich expose some of the
most shaders-friendly decoding operations (like motion compensation,
idct, intra-predictions, deblocking filter and maybe vlc decoding)
through a common API like VDPAU or VA-API.
These APIs can be used to decode mpeg2, mpeg 4 asp/avc, vc1 and
others, but at first I intend to focus on the h264 decoding to save
time, because I know it better and it is currently widely in use, but
again the goal of the project is to be generic.

(2)

In any case, if he successfully makes this VDPAU VP8 decoder state tracker, adding support for H.264, VC-1 etc. later will be much easier than it is now.

[gbeauche]

Totally off topic, but not being an embedded developer guy at all, when I first heard that I didn't believe it. What the hell went through the NVIDIA engineers' minds to make them think that leaving off the SIMD engine for any CPU meant for anything more complex than a toaster is in any way acceptable?

This would have made for a larger die (larger -> more transistors -> more heat) and they probably thought people would use CUDA for multimedia kernels instead. Next-generation Tegra chips will integrate this extension though, IIRC.

[elanthis]

And this is worse when some chips (e.g. Tegra) don't implement NEON extensions to get help.

Totally off topic, but not being an embedded developer guy at all, when I first heard that I didn't believe it. What the hell went through the NVIDIA engineers' minds to make them think that leaving off the SIMD engine for any CPU meant for anything more complex than a toaster is in any way acceptable?

This is why I don't fear mobile devices taking over the PC or game console world. (Maybe the mobile game console world is in trouble, sure, but then only because Nintendo and Sony both are utter morons and either screw over every third-party developer they can or just design whacked out expensive hardware with gimmicky features but only 1/30th the power of my two year old phone.)

[gbeauche]

This whole thing is kind of useless. VP8 on the internet is low-bitrate enough as to not need acceleration. H.264 would be much more important to have on top of Gallium.

This was due to the current lack of HW acceleration at the moment. Google is looking into people to adopt VP8 HW decoding because even current ARM Cortex A9 chips can't handle 1080p VP8 contents. And this is worse when some chips (e.g. Tegra) don't implement NEON extensions to get help. This will change pretty soon, Rockchip already demoed a chip that supports HW VP8 decode. For desktop (PC) GPUs, you still have to wait for N+1 or N+2 generation, depending on the manufacturer. Then, higher bitrate (and quality to begin with) VP8 contents can appear.

[gbeauche]

your ffmpeg patch set just got posted to libav and they have some problem by the look of it ?

http://lists.libav.org/pipermail/libav-devel/2011-April/001240.html

you might want to pop over there or on their IRC if you cant be bothered to follow subscribe there

I follow this list, but in quick read-only mode for now. If they have problems with the vaapi configure parts that are posted, this means they also have problems with the vdpau configure parts that are already in... Otherwise, they are just looking at non problems.

[RealNC]

This whole thing is kind of useless. VP8 on the internet is low-bitrate enough as to not need acceleration. H.264 would be much more important to have on top of Gallium.

[deanjo]

BTW, using VDPAU also locks future development to video decode only.

True, however vdpau does support decoding to system ram and from there you could look at various venues and methods to do your encoding (cpu, gpu even to a separate gpu or multiple GPU's or any combo).

[popper]

VA-API does support encoding. Encoding for E600 does exist today, SNB support will appear next. Even in the future, when AMD implements H.264 video encoding acceleration in their future VCE unit, VA-API can still be a fit.

your ffmpeg patch set just got posted to libav and they have some problem by the look of it ?

http://lists.libav.org/pipermail/libav-devel/2011-April/001240.html

you might want to pop over there or on their IRC if you cant be bothered to follow subscribe there

[smitty3268]

Why adding VP8 support to VDPAU would be easier than for VA-API? In both cases, it's just a matter of adding a video codec ID, and new structures. Even for XvBA, this wouldn't be a problem.

Read the thread, and you'll see this was sort of invented by Michael. Or a misunderstanding, if you want to be more charitable.

Basically, there's already been some work done on VDPAU and the dev is more familiar with it. So they said something like 'i'll just go with vdpau since it will be easier', and michael somehow connected that to adding support for new codecs.

My hope is that once the code for one is done, support for the other API can hopefully be added on top with minimal extra effort.

[popper]

Respond to the thread.

Your reply isn't going to do any good on the phoronix forums.

sure, but Re: [Intel-gfx] ML etc isn't exactly conducive to users or even external x264, ffmpeg/libav, or gstreamer dev's read those mailing lists never mind contribute,

whereas this and other public phoronix thread's do , so it does not harm if some of you/Intel-gfx/MESA come here and start a few tech 'proof of concept' and related discussions and see what happen's

the simple fact is people prefer web message boards today rather than full time mailing lists, many a time the IRC devs dont even read any MESA and related mailing list's as it's more effort for one off comments that may or not get expanded...