AMD Releases UVD Video Decode Support For R600 GPUs

[dungeon]

SSH root access will be not enough?

Not sure, i have no idea what those guys do with firmwares

[chrisr]

Do you really need to disable GL_NV_vdpau_interop?

Ah! Thanks for the notification, that's just a bug. Going to provide a mesa patch.

For the record:
- I have a RV790
- Mesa 10.4-devel advertises GL_NV_vdpau_interop
- "mpr --hwdec=vdpau --vo=opengl" works just fine already with current Mesa git, which disables field-based output.

The field based output is needed to correctly display the picture after decoding. E.g. you will still see the image, but it would be stretched and every second line will come from the wrong offset.

This is what I'm not understanding: Disabling field-based output fixes mpv's video display for both --vo=vdpau and --vo=opengl. And I see no correlation at all between support for field-based output and support for GL_NV_vdpau_interop.

From my perspective, I can see no need to disable GL_NV_vdpau_interop.

[Deathsimple]

This is what I'm not understanding: Disabling field-based output fixes mpv's video display for both --vo=vdpau and --vo=opengl. And I see no correlation at all between support for field-based output and support for GL_NV_vdpau_interop.

Sounds like the fallback works better than I thought. But take a screen shot and compare it (binary) with a VDPAU output. You will find that you only got halve the desired resolution.

The issue is that instead of two views with halve the height of the picture, you got only one view which is used for both the top- and bottom- field.

[brent]

And I see no correlation at all between support for field-based output and support for GL_NV_vdpau_interop.

Please read the spec for NV_vdpau_interop. The extension exposes video surfaces as separate fields. So the video decoder either needs to output fields directly or the frames have to be split up.

[chrisr]

I meant from an "end user" perspective

So the video decoder either needs to output fields directly or the frames have to be split up.

I simply meant that --vo=opengl appeared to be working "just fine" to my feeble human eyes, despite field-based output not being available for the HD4890.

[chrisr]

But this doesn't explain why --vo=vdapu broke with field-based output.

Sounds like the fallback works better than I thought. But take a screen shot and compare it (binary) with a VDPAU output.

You seem to be implying that "--vo=vdpau" doesn't use field-based output, but I assure you that this mode was equally broken before the Mesa patch was applied. I was expecting "--vo=vdpau" to work properly regardless.

[pejakm]

Arch Linux

Arch Linux here, working great with kernel 3.15.10 with grsecurity patch and (s)mplayer.

[oibaf]

So, about R300-R500 is there some help we can provide? Which cards could support it, only RV515 or others? I have a RV530 and could do some tests.

[pali]

So, about R300-R500 is there some help we can provide? Which cards could support it, only RV515 or others? I have a RV530 and could do some tests.

According to wikipedia, RV530 - M66 does not have UVD. M71 is the first card with UVD.

http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units#Mobility_Radeon_HD_2xxx_Series

http://en.wikipedia.org/wiki/Unified_Video_Decoder#UVD-enabled_GPUs

[pali]

So I think there is only one r300g card with uvd: Mobility Radeon HD 2300 (M71). Does anybody have it?

notebookcheck say that these notebooks have this M71 card:

Fujitsu-Siemens Amilo Pi 2530
Sony Vaio VGN-BX41VN
Sony Vaio VGN-CR11Z
Sony Vaio VGN-CR21Z

http://www.notebookcheck.net/ATI-Mobility-Radeon-HD-2300.6940.0.html