AMD Releases Open-Source UVD Video Support

[smitty3268]

I already pointed out that it indicates that it is only capable of mpeg2 decoding, which means its definitely NOT UVD. Mpeg2 really shouldn't take up 30% CPU, even 1080p, except maybe on a crap CPU like an atom.

Which suggests, of course, that even if he has some shader based decoder available, he's still most likely using straight software decoding, and probably decoding some variation of mpeg4. After all... there aren't very many sources of HD mpeg2.

Well, i guess i was assuming that he had tried out playing videos before and after he tried installing the vdpau support, and saw a big difference. Which suggested that he was getting the shader based decoder, rather than nothing, because in that case he wouldn't have seen any difference. But i guess it's possible he didn't even try out the software decoding to compare it.

[droste]

He's probably running mpeg2. I think that indicates the shader based decoder.

The information string is the same with UVD, but "Decoder capabilities" lists for example mpeg4:

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                16  9216  2048  1152
MPEG2_SIMPLE         16  9216  2048  1152
MPEG2_MAIN           16  9216  2048  1152
H264_BASELINE        16  9216  2048  1152
H264_MAIN            16  9216  2048  1152
H264_HIGH            16  9216  2048  1152
VC1_SIMPLE           16  9216  2048  1152
VC1_MAIN             16  9216  2048  1152
VC1_ADVANCED         16  9216  2048  1152
MPEG4_PART2_SP       16  9216  2048  1152
MPEG4_PART2_ASP      16  9216  2048  1152

[droidhacker]

He's probably running mpeg2. I think that indicates the shader based decoder.

I already pointed out that it indicates that it is only capable of mpeg2 decoding, which means its definitely NOT UVD. Mpeg2 really shouldn't take up 30% CPU, even 1080p, except maybe on a crap CPU like an atom.

Which suggests, of course, that even if he has some shader based decoder available, he's still most likely using straight software decoding, and probably decoding some variation of mpeg4. After all... there aren't very many sources of HD mpeg2.

[smitty3268]

... what kind of file are you decoding? Is it mpeg1/2 or mpeg4/h263/h264? If any of the latter, you're definitely software decoding. Notice what it says under "decoder capabilities". Depending on your CPU, 30% may make perfect sense. A Sempron 140 can *almost* handle a 1080p h264 in software, so any middle-of-the-road quad-core would probably take about 30%-ish.

Note that UVD should take about 0%.

He's probably running mpeg2. I think that

Information string: G3DVL

indicates the shader based decoder.

[droidhacker]

My vdpauinfo outputs the following

$ vdpauinfo
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
-------------------------------------------
420     8192  8192  NV12 YV12 
422     8192  8192  NV12 YV12 UYVY YUYV 
444     8192  8192  NV12 YV12 Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                16 262144  8192  8192
MPEG2_SIMPLE         16 262144  8192  8192
MPEG2_MAIN           16 262144  8192  8192

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R8G8B8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
R10G10B10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
B10G10R10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Bitmap surface:

name              width height
------------------------------
B8G8R8A8          8192  8192
R8G8B8A8          8192  8192
R10G10B10A2       8192  8192
B10G10R10A2       8192  8192
A8                8192  8192

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             -
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         -
HIGH QUALITY SCALING - L1        -
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y        48     8192
VIDEO_SURFACE_HEIGHT             y        48     8192
CHROMA_TYPE                      y  
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y  
CSC_MATRIX                       y  
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y  
LUMA_KEY_MAX_LUMA                y

And when playing with mplayer it only uses 30% CPU with perfectly smooth playback. I can actually play at least 2 HD video's at the same time with dynamic resize. Where should I be looking furthur to find if I am using shader based vdpau implementation in mesa or software rendering?

... what kind of file are you decoding? Is it mpeg1/2 or mpeg4/h263/h264? If any of the latter, you're definitely software decoding. Notice what it says under "decoder capabilities". Depending on your CPU, 30% may make perfect sense. A Sempron 140 can *almost* handle a 1080p h264 in software, so any middle-of-the-road quad-core would probably take about 30%-ish.

Note that UVD should take about 0%.

[droidhacker]

It looks like you are using the shader-based implementation.

Yep definitively shader based decoding.

I'm anxious on the RS780/880 support... any news?

[Hugh]

(I'm sorry for my slow response. I didn't get notification of your posting (surely my fault) and I almost never on this forum. This topic is particularly important to me.)

Hal2k1 was mentioning copyright. I included it in the larger list for completeness. Re: patents, the concern there is IP which is currently protected by trade secret but where we have patent applications in flight internally.

OK. That explanation makes more sense.

I don't see how it applies in all cases that we're talking about, but I guess that might be a consequence of it being a secret.

Intel had been working on releasing materials to open source for years before we started. If you said "the sad thing is that in 10 years (or maybe 8, not sure) Intel has reached sufficient performance for video..." I would agree. I'm sure we will reach at least the same level in the same time.

I guess that I wasn't clear. I was rooting for ATI/AMD. ATI/AMD had a significant (large) and consequential (qualitatively important to many Linux users) performance advantage over Intel video. For my purposes, Intel's HD 2000 and up performance is finally good enough: it can do the 3d acceleration (perhaps needlessly) required by modern Linux desktops, and it can reasonably do video decoding. A window has closed.

It's amazing that nVidia, with its closed source drivers, has so much mindshare in the Linux world. It looks to me as if the reason is that they take great care of their Linux driver so that it is almost always up to date with the current production kernels, and it isn't too buggy. ATI/AMD's closed drivers haven't managed that.

ATI/AMD could get a free-er ride with open source. But I admit that the vast majority of the work on the Intel open-source drivers is done by Intel staff.

BTW, IMHO, Years ago, ATI should have harnessed Dave Arlie, not muzzled him.

[fritsch]

What about starting with a look at yadif: http://avisynth.org.ru/yadif/yadif.html?

[Deathsimple]

It looks like you are using the shader-based implementation.

Yep definitively shader based decoding.

BTW: Does anybody volunteer to implement advanced deinterlacing? Or does anybody has a good & open source sample implementation?

Christian.

[agd5f]

It looks like you are using the shader-based implementation.