Thats not really logical, as it worked before for me. But as i only own 1 board but 2 cpus i will not switch back to the i5-680 so soon. currently i prefer to test my i7-880. In the thread i showed you a script that installs libdrm from experimental,but that disabled experimental immediately. Maybe report problems in #videolan on irc.freenode.net. #xbmc-linux is on the same server, but had also some problems there, not sure if you find the one who wrote the vaapi support. But you can of course test it:
Just believe me. On VLC with your script I got either a green artefact slide show or a stutter. And yes, vaapi is used. On the same time mplayer doesn't have any problems. Later I'll try a snapshot with established codecs on my OS instead latest from git. Or do I need the latest? When I think of working mplayer, the answer should be 'no'?!
With a clean vlc and codecs from squeeze + latest vaapi vlc still fails to decode properly. The green artefacts are gone, but there are still some and furthermore stutter. Cpu usage is around 10% when mplayer is around ~5%. mplayer stays my first choice!
It is higher, but it does not matter if 5 or 10%. You can use m2ts subtitles with vlc which you can not use with mplayer. Also ts demuxing is much better with vlc. My vlc script builds ffmpeg, so it uses absolutely latest ffmpeg and nothing from squeeze - or did you modify it?
Did you try 1.1 branch too? It definitely worked for me when i tested it. Do not overrate the cpu usage, that does not matter at all because it still runs in powersave mode, no matter if 5 or 10% usage.
No, I tried only 1.2.git. Yes, but 0% usage also means a deeper sleep state or less wake ups. The other question is, why are there distinct cpu usages if both times vaapi and ffmpeg are the same. Since vaapi is new to vlc, it still has to mature.