#mplayer2

Yesterday I cleaned up my MacPorts — uninstalled gpac, mp4box and such. I followed the dependencies so that libraries like libjack also got uninstalled. Obviously when I previously built mplayer2, several such libraries got linked by auto config, so my mplayer2 won't run anymore. So I set out to rebuild mplayer2.

Somehow, weird things that never happened before occurred this time. No matter whether I build mplayer2 from MacPorts or mplayer2.git, I get the following error:

libmpdemux/demuxer.c:48:2: error: MP_INPUT_BUFFER_PADDING_SIZE is too small! #error MP_INPUT_BUFFER_PADDING_SIZE is too small!

This is due to line 46-49 in mplayer/libmpdemux/demuxer.c:

#include "libavcodec/avcodec.h" #if MP_INPUT_BUFFER_PADDING_SIZE < FF_INPUT_BUFFER_PADDING_SIZE #error MP_INPUT_BUFFER_PADDING_SIZE is too small! #endif

The weird thing is, I checked both macros, and it seems that MP_INPUT_BUFFER_PADDING_SIZE should be less than FF_INPUT_BUFFER_PADDING_SIZE, if libavcodec is from FFmpeg. Evidence:

mplayer2.git/libmpdemux/demuxer.h line 124:

#define MP_INPUT_BUFFER_PADDING_SIZE 16

ffmpeg.git/libavcodec/avcodec.h line 617:

#define FF_INPUT_BUFFER_PADDING_SIZE 32

Obviously, the videolan.org (I mean ffmpeg.org, hosted at videolan) version of libavcodec won't work. We need the libav.org version (you know, the fork of FFmpeg):

libav.git/libavcodec/avcodec.h line 521:

#define FF_INPUT_BUFFER_PADDING_SIZE 8

Further comparison reveals that the two avcodec.h are wildly incompatible. Obviously mplayer2 is using the libav.org version, which also reveals that their dependencies part of README in mplayer2.git is wildly misleading:

Libraries specific to particular video output methods (you'll want at least one of VDPAU, GL or Xv): - libvdpau (for VDPAU output, best choice for NVIDIA cards) - libGL (OpenGL output) - libXv (XVideo output) general: - libasound (ALSA audio output) - various general X development libraries - libass (subtitle/OSD rendering) - Libav libraries (libavutil libavcodec libavformat libswscale) Most of the above libraries are available in suitable versions on normal Linux distributions. However FFmpeg is an exception (distro versions may be too old to work at all or work well). For that reason you may want to use the separately available build wrapper that first compiles FFmpeg libraries and libass, and then compiles the player statically linked against those.

Strictly speaking their general dependencies include "Libav libraries", rather than FFmpeg ("Libav" is a very misleading project name to begin with, since most FFmpeg libraries begins with libav; anyway, this is intentional, since Libav has been pretending to be the upstream rather than the fork from day one). However, to complicate the matter, they are also mentioning FFmpeg.

... (distro versions may be too old to work at all or work well).

I guess that's a nod to the fact that Libav was once distributed under the misleading name ffmpeg in Debian, as the package maintainer fled from FFmpeg to Libav (for some history, see The FFmpeg/Libav situation by an FFmpeg contributor).

(I'm writing this post while exploring the situation, and I finally caught the culprit that broke the build. For the sake of consistency, I'll continue with the story I've been telling.)

So the question now is, how did I successfully build mplayer2 previously?

Looking at port deps mplayer2:

Full Name: mplayer2 @2.0-20131009_0 Fetch Dependencies: git Build Dependencies: pkgconfig, yasm, autoconf, python32, py27-docutils Library Dependencies: libsdl, ffmpeg, XviD, a52dec, enca, faad2, fontconfig, freetype, fribidi, gettext, jpeg, lame, lcms2, libass, libdca, libdv, libdvdnav, libdvdread, libiconv, libmad, libmng, libogg, libpng, libtheora, libvorbis, ncurses, speex, zlib

The mplayer2 port has been depending on ffmpeg, not Libav. In fact, I don't think there is a Libav port in MacPorts.

So, the problem is here after I blamed ffmpeg.git/libavcodec/avcodec.h:

67d29da:

avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32 Sometimes the input buffers get directly used as raw images and SIMD optimized video/image filters can sometimes read more than 16 bytes over the end. a specific example is the AVX 24bpp to yuv code This also fixes fate-vsynth3-rgb Reviewed-by: Christophe Gisquet <[email protected]> Signed-off-by: Michael Niedermayer <[email protected]>

That's it. It was previously 16, but now it increased to 32, and that satisfied the error condition if MP_INPUT_BUFFER_PADDING_SIZE < FF_INPUT_BUFFER_PADDING_SIZE.

Okay, at this point, the natural reaction is to submit a bug report. Then I saw mplayer2's log. The last two commits date back to 2013-10-09, followed by 2013-04-28. Holy crap, so this is actually a dead project... I'm not sure what to do with it now. Obviously I like the exact seeking, but com'on, a dead project will break in no time...

Well, putting other things aside, at least we can build mplayer2 from mplayer2-build.git, right? In fact, not so easy. Libav somehow requires an odd option --cpu=host to gcc, which none of clang, /opt/local/bin/gcc-mp-4.8, /opt/local/bin/gcc-apple-4.2, /usr/local/bin/gcc (4.9.0, built from source) — I mean, any gcc I can get a hold of — recognize. Fortunately I found ticket 240 on mplayer2's trac, which suggests forcing cpu in libav_options:

--cpu=x86_64

which at least solves the building issue. My future of mplayer is still unclear.

http://mpv.io/

I'm testing this right now. It's mostly like MPlayer but it's dynamically linked and doesn't download any external library when compiling (no more ffmpeg installed twice!). It works very much as MPlayer, it has very similar keybindings and options, the main differences are in the command line switch syntax and in the terminal output (which is more clear). Other than in general and no better specified improvements. It supports libquvi to watch YouTube videos from the terminal (a big advantage for many I bet).