Mplayer-vdpau: Matroska (.mkv) and AVCHD (.mts) now both working

Posted on by acme

Nvidia released on 22th its new vdpau driver version 180.18, but not the corresponding mplayer-vdpau. One day later they also released a new mplayer-vdpau. The version 3263604.
I’ve reported a more or less working TwinView for vdpau version 180.18 on a x86_64 Ubuntu 8.10 (Intrepid Ibex), but today the situation look a bit different:

  • Playback in TwinView mode not working
  • VSync working -> No tearing
  • Matroska (.mkv) working

I can’t reproduce the working playback in TwinView anymore, but using only one screen, I can’t see no tearing anymore, and Matroska (.mkv), like AVCHD (.mts) before, works now flawlessly. No stutter, no jerky playback. This error returns, If I start the mplayer-vdpau with an enabled TwinView:

Error 23 at libvo/vo_vdpau.c:791

The CPU load ranges between 2% and 4% on a Q6600 (Intel Quadcore, 2.4Ghz and an Nvidia 8500GT).

Reading the change-log in their README.txt doesn’t sounds very breathtaking, but in fact it’s again a huge step forward. Now Matroska (x264 encodings), as well as AVCHD (Canon HF100 footage) are working flawlessly and this without tearing.

Unfortunately the Xine-vdpau project isn’t performing as fast as the Nvidia/MythTV combo. The hardware accelerated HDTV part of an Media Center is dependent on a working xine-vdpau, and that’s not usable yet.

5 thoughts on “Mplayer-vdpau: Matroska (.mkv) and AVCHD (.mts) now both working”

  1. With this build I was getting the following error with 1080p H.264 mkv files:
    “Error 25 at libvo/vo_vdpau.c:992”

    To fixed this I change line 704 in libvo/vo_vdpau to:
    max_references = ((12 * 1024 * 1024) / surf_size) + 2; //2 more (ugly hack)

    as suggested here: http://www.nvnews.net/vbulletin/showpost.php?p=1882910&postcount=352

    After making the change I ran ‘make’ in the mplayer-vdpau folder ( no need to run checkout-patch-build.sh )

    You may need to increase ‘+ 2’ to something higher depending on the video.

    Thanks acmelab for this blog!

  2. @Kyle Brandt
    I’ve got “Error 25” when trying to play one video, and your suggested solution worked fine. But now I’m getting Error “23 at libvo/vo_vdpau.c:791”, what means there is not enough video memory. Closing all X applications didn’t help, neither did a fresh KDE restart.
    Shouldn’t 512MB video RAM be enough to play a 1080p movie? Strange.

    Regards,
    Andreas

  3. @acmelab68
    I have a 512mb card, and haven’t got that error yet — I have tested at least 10 different 1080p files (full length films).

    This might help: http://www.nvnews.net/vbulletin/showpost.php?p=1877372&postcount=12
    Which I think means you would want to edit the following line:
    #define NUM_VIDEO_SURFACES_H264 17 // (1 frame being decoded, up to 16 references)

    Did you keep the suggested change at + 2 or set it to something higher? The highest I have had to set it is 8…

  4. [UPDATE]the changes below and additionally running Gnome (metacity) and not KDE4.1 (KWin) made all Matroska (.mkv) videos work.
    I’ve noticed this, the moment I went back to the KDE4.1 Plasma desktop, and ran the last tested Video again. It gave me again the “Error 23”. I went back to Gnome and it was fine, back again to KDE resulted in “Error 23”. So it was reproducible every time.
    I wasn’t using either in Gnome nor in KDE compositing (no Gnome’s built-in, not the one of KWin and not Compiz)

    It seams KWin preallocate (wild guess) too much video ram, so mplayer-vdpau can’t to the same anymore.

    With the solution described below, and using Gnome I’ve been able to play all approx. 20 .mkv flawlessly.
    I still had tearing, and turning on TwinView resulted also under Gnome in an “Error 23” again.
    ——————————————-

    @Kyle Brandt
    Hi,
    I didn’t touch line 94

    NUM_VIDEO_SURFACE_H264 = 17

    but set also in libvo/vo_vdpau.c in line 704

    max_references = ((12 * 1024 * 1024) / surf_size) + 11;

    to 11.
    I’ve tested this constellation with approximately 20 1080p movies, and found only one which keeps giving me the “Error 23” thing.

    The solution above is a dirty hack, since the allocation of the memory isn’t calculated, but guessed, and this on a by far too high basis.
    Card with less than 512MB memory and running additional X applications and also using Compiz may run into trouble again.

    Well – I’m going it to use it this way, knowing it’s a workaround and waiting for the next version of mplayer-vdpau.

Comments are closed.