CFT: mplayer and mencoder updates

Tom Evans at
Wed Dec 21 12:58:09 UTC 2011

On Mon, Dec 19, 2011 at 10:35 PM, Thomas Zander
<thomas.e.zander at> wrote:
> Hi list,
> on you can find the
> draft of updates to the mplayer and mencoder ports.
> Please have a look, play with it and let me know what you think.
> I tested it on 8.2 STABLE i386 and amd64 only so far, so I hope it
> works for 9 and 10 as well.
> As always, comments, suggestions and especially patches are more than welcome.
> Best regards
> Riggs

Hi Riggs

I notice in Makefile.shared there is no longer a dependency on
binutils, and there is a patch to define BROKEN_RELOCATIONS.

If you do this, CABAC H264 decoding is ~40% slower on amd64 boxes, and
you lose other speed benefits (SSE2+).

In order to build the best performing, bug free, tested version of
mplayer, you should build with lang/gcc46 and devel/binutils. Both my
ffmpeg and mplayer builds come straight from git master, and work
without patches - in fact, the only thing I must do to build them is
pass configure:
  --with-cc=/usr/local/bin/gcc46 \
  --with-as=/usr/local/bin/as \
  --extra-libs=-L/usr/local/lib \
  --extra-cflags=-I/usr/local/include \
  --prefix=/usr/local --mandir=/usr/local/man

In a similar vein, mplayer's configure does not check for existence of
a feature if you explicitly bake it in. For instance, the libbluray in
freebsd ports is not up to date with the version required for mplayer,
but selecting "bluray" from OPTIONS forces mplayer to build it in.
If it was not forced, mplayer's configure would detect the library is
there, but of an older version, and it would not attempt to compile in
bluray support, and you would not get build errors.

I'm going to go through the patches in files directory and see what
can be pushed back. I think most of them fix issues with libraries I
don't use (gsm, udp, arts) or with features that I don't use
(libao-oss - well, I use SPDIF).



More information about the freebsd-multimedia mailing list