AMD's UVD2-based XvBA Finally Does Something On Linux

[bridgman]

Bridgman thanks for the point by point response, I know it was a pretty annoying post.

I agree that GL video output, does work fairly well, but at the cost of CPU. I know the "modern CPU" argument, but when there's a piece of hardware on your graphics card, that is specifically capable of making the CPU irrelevant, but there's not a way to use it, it's easy to get raised expectations. I was at least under the impression that we would see broader and more complete coverage of the streams that UVD2 is capable of handling. I realize it's early but from statements made here it sound like the development will only be toward specific use cases as opposed to all that UVD2 is capable of. Hopefully I'm wrong with that impression.

I'm glad you posted more details; I may be able to ease your mind a bit.

We normally describe the video playback stack in two parts; decode, and render (or presentation). Decode goes from a bitstream representation to some kind of YCbCr image in the video's native resolution - render/presentation goes from that image to a filtered RGB image in the resolution you want on the screen. The UVD only handles decode functions; everything else is done in shaders anyways.

There are a variety of acceleration APIs available for doing the render operations, including OpenGL, Xv, the bottom end of VA-API and VDPAU, a variety of proprietary APIs, or software rendering to an X11 surface. Other than software rendering, they all use roughly the same amount of CPU, although OpenGL will tend to use a bit more because there is some general purpose code between the API call and the shader invocation. The difference is pretty small though.

The important point here is that you are not "leaving hardware capability unused" - UVD goes from H.264/VC-1 bitstream to YCbCr native resolution, and does IDCT/MC processing for MPEG2. That's all it does on any OS. I believe the same is true for our competitors hardware as well.

I made a long post a few months ago showing the entire stack; will see if I can find that and link to it here.

The embedded question only became clear, when you directly said it in this thread in the past day or so. The articles on this site and the Wikipedia page don't say it, in fact they present it as requiring a 4000 series or later card and the proprietary ATI driver. They also present it at as direct replacement for XvMC and competitor to VPDAU as well as DxVA which certainly are not embedded only. I guess the error in these statements come from the fact that none of these are ATI statements, but rather statements by supposed insiders. Incidentally most of the in info out there points back to this site.

AFAIK the articles came from some good old fashioned investigative reporting (picking through the binaries, calling around to dig up bits of leaked information, putting the bits together into an overall picture..), and they're pretty close. What they missed was that we were targetting the sealed-box embedded market at the time, not general consumer use.

As far as the "silence" - You specifically are very good at relaying information without ambiguity but there are others here that seem to enjoy it. So, yeah, there are some posts were I wish the beta team member that wants to play "I know something you don't know" would not say anything at all.

Have some sympathy for the devs working under NDA. They usually start talking about safe things and trying to help, then get herded towards areas they are not allowed to discuss. I really believe that if people here didn't beat on them for more details then you wouldn't see the "I can't tell you" responses.

[RemcoL]

What they missed was that we were targetting the sealed-box embedded market at the time, not general consumer use.

(emphasis mine)

In the past it was the embedded market, now it's the general consumer market. I think this is exactly what people here wanted to hear.

The only thing is that it all looks to go soooo sloooowwwww from the outside

[bridgman]

I think the priority for video decode is still the embedded market, but we are trying to push consumer support ahead as well.

[rjwaldren]

I think the priority for video decode is still the embedded market, but we are trying to push consumer support ahead as well.

That's good to hear, I do hope it includes IDCT/MC as well as H.264/VC-1. Honestly if the color range issue with Xv, XvMC was fixed it would go a long way in combination with the current XvBA implementation. In my system both Xv and GL perform much better than the OSS drivers, but Xv colors look terrible with fglrx.

I don't simply use my systems to play video, I'd rather the specialized HW that is design to handle video decoding - handle it. I'm also using the same box as terminal and file server. The cpu usage never gets too high when under these uses but when combined the video stutters badly, most of the load is going to decoding. Yeah it was easy pushing 480 and lower MPEG2 content to a SD TV, but it's notched up with pushing 720 and 1080 to 1080p screens as is becoming the norm.

I've been a long time ATI fan boy in Windows, but it's been about 6 years since I last bothered with ATI under linux. First boot with the 4850 and fglrx and my 60in DLP had a perfectly scanned/centered 1080p picture without the need for special modelines or tweaking - NV or the ATI oss have never done that. Incidentally the 6 year old card recently started working wonderfully with the new r300 stack.

[arbitrabbit]

@Kano @Non7stop

I am having the same problem as Non7top. Trying to run an an HD video, where format is

Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]

But get the same error message on Ubuntu Karmic

MPlayer SVN-r29912-4.4.1 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing downloads/complete/Dugs_Special_Mission_1080p_BluRay_x264_DVSKY/dugs.special.mission.1080p.bluray.x264-dvsky.mkv.
[mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0
[mkv] Track ID 2: audio (A_AC3), -aid 0, -alang eng
[mkv] Will play video track 1.
Matroska file format detected.
VIDEO:  [avc1]  1920x1080  24bpp  23.976 fps    0.0 kbps ( 0.0 kbyte/s)
[vo_vaapi] Using OpenGL rendering
libva: libva version 0.31.0-sds3
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
libva: va_openDriver() returns 0
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
[VD_FFMPEG] VA API accelerated codec.
Unsupported PixelFormat 53
Unsupported PixelFormat 53
[VD_FFMPEG] Trying pixfmt=0.
Unsupported PixelFormat -1
Unsupported PixelFormat 53
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
[VD_FFMPEG] Trying pixfmt=1.
Unsupported PixelFormat -1
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
Unsupported PixelFormat -1
Unsupported PixelFormat -1
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Forced audio codec: mad
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 640.0 kbit/41.67% (ratio: 80000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
[h264 @ 0x8a57fa0]decoding to PIX_FMT_NONE is not supported.
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]decoding to PIX_FMT_NONE is not supported.
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]decoding to PIX_FMT_NONE is not supported.
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]B picture before any references, skipping
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]decoding to PIX_FMT_NONE is not supported.
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]B picture before any references, skipping
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]decoding to PIX_FMT_NONE is not supported.
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!
[h264 @ 0x8a57fa0]B picture before any references, skipping
[h264 @ 0x8a57fa0]decode_slice_header error
[h264 @ 0x8a57fa0]no frame!
Error while decoding frame!

Too many audio packets in the buffer: (4099 in 10493440 bytes).
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.

FATAL: Could not initialize video filters (-vf) or video output (-vo).



MPlayer interrupted by signal 6 in module: free_demuxer
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.

[eigerhar]

HIS Radeon HD 4350 PCI

Finally an UVD2 card that works with my embedded PC (without AGP and without PCI-e).

http://www.newegg.com/Product/Product.aspx?Item=N82E16814161283

UVD2 that should work with Linux!!!

But now I'm reading, that in this card video acceleration is not activated in Vista and XP. You need a proprietary tool to enable this function: DXVAchecker.

http://forums.amd.com/game/messageview.cfm?catid=279&threadid=116888

Is it possible to use this card together with Linux and accelerated h.264?
What about video acceleration in Linux?

[droidhacker]

@bridgman:

Q's: What is the feasibility of doing a 100% (or near to) software-on-GPU (i.e. openCL) based video acceleration? How strong of a GPU might this need (I know, subject to implementation, etc.) for BD-level video streams? And assuming that we end up getting some kind of openCL via G3D that works for older GPUs, is it possible that something like this could work for some older (i.e. R6xx - UVD-1) chips -- which currently aren't supported either for openCL or for XvBA?

[gururise]

Does anyone know how feasible it would be to write a XvBA->VDPAU back-end for fglrx?? It seems that now VAAPI has been left in the dust as more and more linux media players are announcing support for VDPAU.

[mirv]

Does anyone know how feasible it would be to write a XvBA->VDPAU back-end for fglrx?? It seems that now VAAPI has been left in the dust as more and more linux media players are announcing support for VDPAU.

vdpau is an api from nvidia.
va-api can use vdpau as a backend, or hopefully xvba. Software only need support va-api, and then they can "support" whatever backend va-api uses. So there's no real point to a xvba->vdpau.

[gururise]

vdpau is an api from nvidia.
va-api can use vdpau as a backend, or hopefully xvba. Software only need support va-api, and then they can "support" whatever backend va-api uses. So there's no real point to a xvba->vdpau.

Perhaps I was unclear. I meant if we could use VDPAU apps on FGLRX. IE.. If we could run vdpau applications on our Radeon cards, it would instantly open up a whole slew of hw assisted decode video applications such as Mplayer, ffmpeg, xbmc, mythtv, and vlc media player... all of which support VDPAU and none of which support VA-API (at least in their mainline). So I am suggesting that perhaps VDPAU support for Radeon would have been better than VAAPI.