FFmpeg Gets Mainline VDPAU Support

[phoronix]

Phoronix: FFmpeg Gets Mainline VDPAU Support

When NVIDIA introduced VDPAU support in November for providing excellent GPU playback support on Linux they released a set of patches that enabled the Video Decode and Presentation API for Unix support within the FFmpeg and MPlayer projects. Initially it looked like these patches would not be accepted into the mainline code-base, but committed to the FFmpeg repository last night was support for VDPAU.This patch adds in support for hardware-accelerated H.264 video decoding using VDPAU...

http://www.phoronix.com/vr.php?view=Njk3MQ

[[Knuckles]]

If this means that we can have VDPAU in XBMC Media Center it would TOTALLY ROCK.

Nvidia, sell me one of those small boxes with atom and a nvidia chipset NOW!

[deanjo]

;57588']If this means that we can have VDPAU in XBMC Media Center it would TOTALLY ROCK.

Nvidia, sell me one of those small boxes with atom and a nvidia chipset NOW!

Well it was one of the major reasons for it not being integrated in XBMC. Now that objection is gone.

BTW: New ffmpeg packages supporting vdpau are already packaged up for opensuse on the Packman repo

[yoshi314]

i find it hard to believe. i thought ffmpeg would always steer clear from having proprietary dependencies (such as nvidia driver backend in this case, unless i am missing something).

oh well, i guess i was wrong.

[bridgman]

It seems like an easy way to avoid being bypassed in the future. That might sound harsh but I don't mean it that way. Right now ffmpeg is a pretty universal solution and lots of things build on it, but as full decode APIs start getting added to drivers the player devs could simply bypass ffmpeg and go straight to the driver. If ffmpeg includes a path to VDPAU it means player developers don't have to change anything and can keep using ffmpeg as they did before.

They probably feel a bit dirty, but the alternatives all require about 20x as much work and a lot more time...

[myxal]

I was under the impression the API was public? As long as that's true, what does it matter that the only implementation so far is proprietary? :confused:

And with that in mind, now that we have an acceleration API that's used in (most of?) the Linux video players, question at bridgman or whoever's got docs to Radeon ASICs - would it be (theoretically) possible to implement VDPAU in radeon or radeonHD? If so, what's your take on it - would you support it?

[Vadi]

That code is mind-warping.

[russofris]

Hi there,

While this is a nice + for the video playback crowd, what does this mean to those that do transcoding (via mencoder or, well, transcode). Has anyone had the opportunity to compare performance under ffmpeg-enabled video applications.

I realize that VDPAU only supports decode, but it should certainly have an effect on video content creators and editors mixing down multiple h264 streams.

F

[eric.frederich]

Will this get rid of video tearing in Linux?

I get it on 2 different systems with NVidia cards. I have tried different mplayer -vo options. Tried Totem, and other players. I have sync to vblank enabled when I go to the nvidia x server settings gui.

[myxal]

That code is mind-warping.

Hmm, anyone looked at nVidia's diagram? >
ftp://download.nvidia.com/XFree86/vdpau/doxygen/vdpau_data_flow/vdpau_data_flow.png

"Can't you see? It's perfectly clear!!" :D

[deanjo]

Will this get rid of video tearing in Linux?

I get it on 2 different systems with NVidia cards. I have tried different mplayer -vo options. Tried Totem, and other players. I have sync to vblank enabled when I go to the nvidia x server settings gui.

Disable any compositing (ie Kwin4 or compiz) you have before running vdpau. That is the source of most tearing.

[_txf_]

Disable any compositing (ie Kwin4 or compiz) you have before running vdpau. That is the source of most tearing.

I'm surprised that he doesn't get any tearing with non-vdpau videos. According to nvidia, If you are using compositing sync-to-vblank is disabled in xv (and opengl output), let alone vdpau.

One can also just play the video full screen which unredirects the texture, bypassing the compositing manager (in kwin4 and compiz).

BTW: New ffmpeg packages supporting vdpau are already packaged up for opensuse on the Packman repo

really? 'cos I don' see it
EDIT: according to the site there was an update 3 hours ago,I must be using a mirror.My Bad...

[deneb]

Will this get rid of video tearing in Linux?
With the MPlayer patch, the VDPAU vo may help, but you should be able to get tear-free video playback also with XVideo and OpenGL when you have disabled compositing. First, make sure you enabled "Sync to VBlank" for XVideo too, not just for OpenGL. If "-vo xv" still shows the problem, try "-vo gl:yuv=1".

[popper]

Hi there,

While this is a nice + for the video playback crowd, what does this mean to those that do transcoding (via mencoder or, well, transcode). Has anyone had the opportunity to compare performance under ffmpeg-enabled video applications.

I realize that VDPAU only supports decode, but it should certainly have an effect on video content creators and editors mixing down multiple h264 streams.

F

its not just transcoding OC, any HW assisted processing you manage to move off the CPU(s) means at the very least, your saving lots of CPU cycles, and so your CPU(s) can be doing other related video processing needs on a given workflow/timeframe.


and apparently FFMPEG CPU code doesnt currently give you working frame accurate framebuffer editing,it has some problems with that, the HW gfx cards can/could give you that for free as well as MBAFF and PAFF decoder options,potentially helping with AVCHD, and lossless AVC Intra in your transcoding too.

[yesterday]

I was under the impression the API was public? As long as that's true, what does it matter that the only implementation so far is proprietary? :confused:

And with that in mind, now that we have an acceleration API that's used in (most of?) the Linux video players, question at bridgman or whoever's got docs to Radeon ASICs - would it be (theoretically) possible to implement VDPAU in radeon or radeonHD? If so, what's your take on it - would you support it?

VDPAU is an interface to NVIDIA hardware using the proprietary driver. The API is pulbic to allow projects to access the NVIDIA hardware for GPU decoding. For radeon/radeonhd, not only do we need some interface to expose the ATI hardware, but the code to support this in the driver must be open source. ATI are coming up with some API to UVD/UVD2, which will most likely be public, but will also most likely be limited to fglrx. I believe bridgman wrote somehwere on phoronix that there is very little chance of ATI providing details to accessing the UVD hardware, meaning the GPU decoding in OS drivers will be a long time coming, and through different means (OpenCL maybe). It would be very gracious for AMD to adopt the VDPAU interface for their proprietary driver, but pretty unlikely since they've been working on their own solution for sometime.

[Kjella]

It would be very gracious for AMD to adopt the VDPAU interface for their proprietary driver, but pretty unlikely since they've been working on their own solution for sometime.

There's not really that many ways to skin that cat, there's basicly two options:

1) Slice-based, where you pass compressed frames to the decoder and they "magically" come out decompressed
2) Function-based, where you expose the different parts you can do like MC/IDCT/CABAC etc. and the software decoder calls the parts.

The nVidia decoder is slice-based, pass stuff through a VdpDecoder and out comes a VdpVideoSurface. If AMD went down that route, they could name the buffers a little differently but it'd be the same.

If it's function-based, then you have to implment something to call the AMD bits and do software decoding of the rest. Maybe a little pseudocode is easier:

if ( software ) {
SW_Entropy();
SW_IDCT();
SW_MC();
SW_CABAC();
} else if ( function-based ) {
SW_Entropy();
HW_IDCT();
HW_MC();
SW_CABAC();
} else if ( slice-based ) {
HW_decode();
}

There was some talk of this in another thread, basicly the API is the least of the problems. If some variation of HW acceleration comes out from AMD, it'll get implemented no matter the API.

[npcomplete]

Wow, finally I guess. So did they improve on what it can actually decode? Or is it still limited to main and high profile settings only?

[djtm]

what does this mean to those that do transcoding
In my tests it did not work when transcoding: Cannot find codec matching selected -vo and video format 0x10000005.