FFmpeg Gets Mainline VDPAU Support

[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?

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.