[MPlayer-users] Acceleration works in xbmc, not in mplayer

Grant emailgrant at gmail.com
Thu Sep 11 02:35:09 CEST 2014

>> > I upgraded from libvdpau-va-gl-0.3.4 to the live version from git and
>> > now it's working!  It looks like I can only decode H264:
>> >
>> > Decoder capabilities:
>> > name               level macbs width height
>> > -------------------------------------------
>> > H264_BASELINE        51 16384  2048  2048
>> > H264_MAIN            51 16384  2048  2048
>> > H264_HIGH            51 16384  2048  2048
>> >
>> > Is that a hardware or software limitation?  If software, which package
>> > should I watch for new codec capabilities?
>> Is that vdpauinfo or vainfo output?
>> If these differ, then then the limitation is in libvdpau-va-gl
>> If vainfo also only reports H.264 then it's a limitation in Mesa
>> (which might be due to the hardware limited to that).
>> Though either way, my question would be: what else would you
>> expect/need? Most other formats should be fine without hardware
>> acceleration, at least if you enable threads.
> It seems the other formats supported are MPEG-2, JPEG, and VC-1.
> JPEG acceleration we cannot use anyway, MPEG-2 should be useless
> speed-wise.
> VC-1 can be relevant if you want to play BluRays, however it
> is more lightweight than H.264 so I still think you should
> manage just fine with CPU-only.
> Though for a bit less fan noise you might ask the va_gl developers
> about adding support, this seems to clearly say that they only
> added H.264:
> https://github.com/i-rinat/libvdpau-va-gl/blob/master/src/api-video-decoder.c
> Though as said, the reason is probably that it's the only
> format they considered necessary, so you might need
> some convincing arguments as why other formats should be added.

Well, I'm running this on a fanless Gigabyte Brix 2807:


Do you really think I can decode 1080p VC-1 in software with threads?
I don't have any VC-1 to test with ATM.

- Grant

More information about the MPlayer-users mailing list