If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
mplayer works well, but I can't get the gstreamer vaapidecode to work (vappiconvert and vappisink work, though).
How do you use it? What kind of video file? What version of gstreamer? Just saying "doesn't work" doesn't help much. If your videos are embedded in a .ts container, then there indeed could be decoding -- well, parsing -- problems.
What driver are you using? The problem in XBMC was not a video size problem. That is, the video was jittering a lot unless you showed the controls panel. Most likely an FBO problem. This problem also occurred on Windows. I doubt it was fixed.
vlc git shows green.
Clip? VLC version?
h264 l5.1 does not work.
If this works on Windows, I believe there are probably means to get them to work in Linux too.
tar/deb latest links are swapped, so i made a hotfix script:
Fixed. Links to 0.7.0 binaries were also reversed yesterday but nobody noticed.
Arch Linux packages are generally current. Use either upstream 0.31.0 (so called "1.0.1") without any patches or libva-sds 0.31.1-1+sds3. I just saw some packages built this morning. This might work now.
By the time there are usable radeon Gallium drivers, VA-API will be completely obsolete, since there is a WIP VDPAU state stracker.
Ah, because you believe there is a WIP VDPAU state tracker implies that (i) the actual decoders are available, (ii) they are efficient and effective, (iii) magically support all other HW like ATI, Intel G45 and GMA500? The answer to all of those is "no". I don't see how the API can be obsolete when it has implementations for every single combined GPU+HW accelerator in Linux.
While the solution may be not so good I actually can watch hd videos with < 10% CPU load extremely smooth...
What can nvidia users with vdpau do that I can't?
Memory leaks and corruption in the long run, thus leading to system crashes. Much less features exposed in XvBA/GL than in another XvBA backend. Suboptimal use of GPU memory resources because of driver bugs or things not fully implemented. i.e. another indirection to accomplish the expected task, thus requiring more memory (and work). Some sync problems in the pipeline, depending on the driver (regression). etc.