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

[gbeauche]

Auto-detection also works as I get the same picture now without the env variable. But as you can see there's still a horizontal strip of garbage present in the picture. And with the --glx variant there's also a small vertical white line on each side of the picture.

I can only re-order the blocks, not create them from scratch. The fglrx driver ate the remaining blocks during the transfer to the GL texture, there is nothing more I can do... And I'd better not try further because I am starting to imagine ways I could mutilate ATI devs if I catch some: removing eyes with a screwdriver, cutting off fingers with a knife, egyptian removal of brain through the nose, etc. those don't seem to be used anyway. Bye, I am switching to more pleasant things.

[Smask]

Hey gbeauche!

Did you use GMask source in the new version? It sure looks like hGlass and vGlass.

[gbeauche]

Did you use GMask source in the new version? It sure looks like hGlass and vGlass.

I don't know what it is. However, a friend of mine pointed me to some interesting academic documentation. e.g. baker's transformation and other bijective image transformation algorithms. Fortunately, the patterns showed in the above captures were obvious enough.

[Smask]

I don't know what it is. However, a friend of mine pointed me to some interesting academic documentation. e.g. baker's transformation and other bijective image transformation algorithms. Fortunately, the patterns showed in the above captures were obvious enough.

FLmask(Mac), and later GMask(PC), were developed for sneaking past Japanese porn censors. Certain parts of images containing nekkid wimmins were scrambled. The porn connoisseurs could then download and unscramble them. The author of FLmask went to prison for this stunt. He hosted a japanese porn site containing masked images (Images that can be altered so you can se the twat is a big nono in Japan ).

Some of the masking filters in FLmask/GMask looks very similar to those images posted here in the thread. Linux sources is available for GMask, but they're written using gtk+ 1.22 with no Makefile and comments written in Japanese...

[DarkFoss]

Wow Thank you Gbeauche,

Thank you also Monraaf and Dandel!

I just watched a high def version of Doctor Who as well as played Kano's fav PlanetEarthBirds.mkv several times,on my 5770. Using xvba-video-0.7.6.pre2.x86_64.
With the mplayer -vo vaapi:gl -va vaapi PlanetEarthBirds.mkv command there is a 1 inch garbage border.. However using
mplayer -vo vaapi:reflect -va vaapi PlanetEarthBirds.mkv there is no garbage borders at all..other than a cpu spike of 17% cpu usage is neglible.. The only error message is :

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  [zoom]
[VD_FFMPEG] XVMC-accelerated MPEG-2.
A: 112.4 V: 112.4 A-V:  0.000 ct:  0.013   0/  0  1%  2%  0.4% 9 0

XBMC also shows the 1 inch border along the bottom but otherwise playback is flawless..but XBMC hangs x on exit and I lose any debug messages both on Gnome and KDE 4.6 .
I'm using Mandriva 2011(cooker) upgraded from 2010.1.. I have some issues that prevent me from compiling the hwdemos so I can't contribute anything more..perhaps a clean install this weekend will clear thiings up a bit.

[DarkFoss]

Sorry,
Darn lack of edit.. I forgot to mention this is on the leaked Cat 10-10 rc driver.

[gbeauche]

With the mplayer -vo vaapi:gl -va vaapi PlanetEarthBirds.mkv command there is a 1 inch garbage border..

I believe this one inch band is the usual 8-pixel tall garbage. Yes, it appears that the bug exhausts differently depending on the GL context. Native XvBA hwdecode-demos and players exhibit similar problem. Fortunately, the workarounds I set up work correctly on the chip I use, without extra garbage, and this is what matters.

XBMC also shows the 1 inch border along the bottom but otherwise playback is flawless..but XBMC hangs x on exit and I lose any debug messages both on Gnome and KDE 4.6 .

The XBMC crash log is normally dumped to file, in the directory from where you started it. Could you please try to start XBMC from a terminal? Anyway, I also get a crash on XBMC exit and a "normal" RS780. IIRC, this was crashing in the ADL (AMD Display Library). A native XvBA player sometimes crashes on exit too, depending on the version of the fglrx driver. So, this could also be a factor.

[DarkFoss]

Xbmc crashlog

Dmesg fglrx

[larry@Tardis-2 ~]$ dmesg | grep fglrx
fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[fglrx] Maximum main memory to use for locked dma buffers: 3798 MBytes.
[fglrx]   vendor: 1002 device: 68b8 count: 1
[fglrx] ioport: bar 4, base 0xee00, size: 0x100
[fglrx] Kernel PAT support is enabled
[fglrx] module loaded - fglrx 8.78.6 [Oct  5 2010] with 1 minors
fglrx_pci 0000:01:00.0: irq 40 for MSI/MSI-X
[fglrx] Firegl kernel thread PID: 1114
[fglrx] IRQ 40 Enabled
[fglrx] Gart USWC size:1240 M.
[fglrx] Gart cacheable size:491 M.
[fglrx] Reserved FB block: Shared offset:0, size:1000000 
[fglrx] Reserved FB block: Unshared offset:f91f000, size:3e1000 
[fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000 
[fglrx] IRQ 40 Disabled
fglrx_pci 0000:01:00.0: irq 40 for MSI/MSI-X
[fglrx] Firegl kernel thread PID: 8046
[fglrx] IRQ 40 Enabled
[fglrx] Gart USWC size:1240 M.
[fglrx] Gart cacheable size:491 M.
[fglrx] Reserved FB block: Shared offset:0, size:1000000 
[fglrx] Reserved FB block: Unshared offset:f91f000, size:3e1000 
[fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000

rest later back to work

[DarkFoss]

vainfo

[larry@Tardis-2 ~]$ XVBA_VIDEO_DEBUG=1 vainfo
libva: libva version 0.31.1-sds1
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib64/va/drivers/fglrx_drv_video.so
xvba_video: FGLRX driver version 8.78.6 detected
xvba_video: FGLRX device ID 0x68b8
xvba_video: Evergreen GPU detected
xvba_video: XvBA version 0.74 detected
libva: va_openDriver() returns 0
vainfo: VA API version: 0.31
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.7.6.pre2
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointIDCT
      VAProfileMPEG2Main              :	VAEntrypointIDCT
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD

Glxinfo

[popper]

VLC copies the decoded video back to the CPU before displaying it, while other programs just pipe the output straight to the monitor.

This was done intentionally, so that they can send the decoded video through their whole existing pipeline of filters, etc., and doesn't just do a dumb display to the screen.

For most people that's not very important, but it is nice for some.

actually as i understand it, it's far more important as a basic generic need than its made out to be.

as VLC and Mplayer and indeed many others are actually using the FFMPEG code-base, so thats why all UVD video related patches should really be back parted to that FFmpeg current code base and the x264 code base too.

after all it is the x264/FFmpeg C/assembly dev's that gave you the worlds fastest VP8 http://x264dev.multimedia.cx/, and best visual quality x264/H.264 Encoder in the world , so show some support and port those new and existing patch's to their code-base, and get some code optimizations back in return, as they DO Seem to like making existing code (patches welcome) better and faster.