XvBA on Evergreen

[bridgman]

There was an active discussion about this going on in an NVidia forum; figure we should probably move it back to the ATI/AMD forum so everyone can find it easily.

Current status in a nutshell is that our internal testing (which focuses on the NDA version of the API) indicates that XvBA is working on Evergreen, while end user experience (using gbeauche's VA-API adapter) is that Evergreen support does not work. The problem seems to be related to a specific function call used when running XvBA decode with GL output, which gbeauche apparently identified some time ago.

I don't know if the problem has been reproduced in the multimedia driver team; will try to chase that down next week.

[markg85]

I just tested XvBA on my 5770 card with the newest XvBA VA-API backend and the lateest mplayer-vaapi version. I get an extreme number of artifacts and the image is not even recognisable.

While playing i get tons of the following message in mplayer:

MPlayer SVN-r31303-4.5.0 (C) 2000-2010 MPlayer Team
154 audio & 334 video codecs

Playing /media/dvdimage/BDMV/STREAM/00004.m2ts.
TS file format detected.
VIDEO H264(pid=4113) AUDIO DTS(pid=4355) NO SUBS (yet)! PROGRAM N. 1
FPS seems to be: 23.976025
libva: libva version 0.31.0-sds6
Xlib: extension "XFree86-DRI" missing on display ":0.0".
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.
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
================================================== ========================
================================================== ========================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
Selected audio codec: [ffdca] afm: ffmpeg (FFmpeg DTS)
================================================== ========================
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
[VD_FFMPEG] Trying pixfmt=1.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vaapi] 1920x1080 => 1920x1080 H.264 VA-API Acceleration [fs]
[vo_vaapi] Using 1:1 VA surface mapping
[VD_FFMPEG] XVMC-accelerated MPEG-2.
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!/ 5 ??% ??% ??,?% 3 0
[ASPECT] Warning: No suitable new res found!
....
[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one
....

Keep us posted about the progress.

Regards,
Mark

[markg85]

Oh, when testing the same file on a 4xxx card i also get a lot of those messages:

[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0xd51be0]number of reference frames exceeds max (probably corrupt input), discarding one

but the video plays just fine with UVD hardware acceleration.

[Kano]

I verified the same using ATI 4550 (xvba works up to h264 l4.1) and ATI 5670 (xvba always shows crap). It is really annoying when the "internal" tests are made with an interface that's not useable for end users. Why is it so critial to hide some header files? Nv does not have this problem also vdpau works with h264 l5.1 too (when you use properly patched ffmpeg also divx) - also xvba does not have mpeg2 VLD accelleration. It is very hard to recommend ATI for a Linux htpc because when you leave the supported mplayer vaapi path you only see problems. xbmc can at max show videos with size % 16 = 0 which is usually never true for 1080p. vlc shows just green. You can not blame the app devs for those issues when the driver has too many problems. ATI has to work on those issues because just providing OpenGL 4 for cheaper cards is not enough. When you consider how long those issues are known and the only problem that was fixed was a color change problem with h264 material (with 10-5 driver) which existed since the first public xvba-video wrapper was available (9-10) then this says all.

[smitty3268]

I'd say you're being too kind, Kano. I've always rooted for AMD, although i'm not as huge a fanboy as some, and even I can't think of any scenario where I would actually recommend an ATI card for a linux HTPC. I'd have to say go Nvidia or else get Windows, because the XvBA situation on linux just isn't working and there's no sign it's going to get any better. At least with other fglrx issues AMD seems to at least be working on them and there's hope that things will improve.

Even on Windows, ATI seems very limited in what they do with VA compared to NVidia. Check out the recent VLC 1.1 release which ATI doesn't work with because they need access to some magic GUID to enable getting the video output back to the application. I don't know if ATI's hardware design just doesn't allow them to share any information or what - it's strange to think that NVidia's lawyers/decision makers are more willing to be open than AMD's but that appears to be the case with video.

[LinuxID10T]

For all those who might not have seen it on the last thread h.264 l5.1 with QFHD is definitely not a go (testing on a Radeon HD 4650.) Interesting enough it causes a hardware video card crash.

[markg85]

Above me the idea to let ATI just "give" the required headers is, yet again, posted. I don't think that's a good idea.

You see, that other user on these forums here that made the XvBA VA-API backend has the required ATI docs/headers under NDA so you would think that he would be able to make a good XvBA VA-API driver right? Well, wrong. As he said on some post here there is a BUG in the implementation of the header file -- which is not released by ATI, not even under NDA if i'm right -- thus that poor user can't fix a thing.

So, to cut a long story short. The headers are useless if the header implementation, the source, contains bugs. This is where ATI is needed to fix the source files. That user even pointed out to bridgman which function (in a hint) needs to be fixed so ATI should no where to look and just fix it.

As for testing. I don't know how ATI tests this stuff or opengl 4 stuff but something is obviously wrong here since XvBA is broken on 5xxx cards and opengl 4 tesselation is (on windows, not tested on linux) still heavily corrupted.. something a simple visual test done by a HUMAN would heve been detected.

[markg85]

ATI should no where = ATI should know where

damn you phoronix for not letting me edit posts.. -_-

[bridgman]

Huh ? I don't think anyone said anything about a bug in the header file. What gbeauche was saying was that there was a bug in one specific API function in the driver.

The testing issue seems to be that XvBA itself is working but there's a problem with the GL render output after XvBA has finished decoding the frame. The GL render path is something we added for consumer use and have not released yet.

Most of the testing focus is using the NDA-only render path developed for ISVs shipping binary player apps, and it looks like there's not enough testing on the GL output path.

[Kano]

Do you think it logical to use NDA for xvba? I don't think so. Nvidia does not need that for vdpau too. With an open sdk mplayer could at least use the working code path.