ffmpeg 2.3 (specifically, avcodec.h in libavcodec) breaks building of mplayer2

[zmwangx@…]

mplayer2 requires the Libav.org version of libavcodec to function. Previously the VideoLan.org (I mean, FFmpeg.org) version of libavcodec also works, and the mplayer2 port depends on that. However, a recent change to FFmpeg breaks it. Specifically, in the 2.3 release, due to ​commit 67d29da, which says,

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

The requirement

#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

in ​mplayer2.git/libmpdemux/demuxer.c is broken, since MP_INPUT_BUFFER_PADDING_SIZE is 16 as defined in ​mplayer2.git/libmpdemux/demuxer.h.

This is clearly reflected in the following error when running port install -v mplayer2:

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

[zmwangx@…]

The title should read "New version of FFmpeg (specifically, avcodec.h in libavcodec) breaks building of mplayer2". Sorry for the typo.

[dbevans (David B. Evans)]

Please CC the port maintainers when submitting a ticket and leave the priority field for the use of MacPorts management.

Sounds like this is an issue that should be handled upstream (mplayer2 or ffmpeg as might be appropriate). Are you suggesting a particular solution to the problem?

[zmwangx@…]

Sorry for the priority and CC.

I don't think this can be handled upstream since

• FFmpeg is changing for the better, there's no reason for them to roll back for compatibility with MPlayer or mplayer2;
• Strictly speaking, mplayer2 depends on Libav (which is a fork of FFmpeg) rather than FFmpeg; FFmpeg just happened to work by being mostly compatible with Libav;
• The mplayer2 project itself seems largely dead, the latest commit on master dating back to October 2013. (Anyway, the same problematic code seems to also appear in the latest svn version of MPlayer.)

However, the mplayer2 project itself does have a ​mplayer2-build.git repo that correctly handles its own dependencies, at the cost of building its own version of libavcodec, etc. mplayer2-build works fine at least at this moment (there's no guarantee for the future, though).

[dbevans (David B. Evans)]

Thanks for the background. Does increasing MP_INPUT_BUFFER_PADDING_SIZE to 32 fix the problem for you?

[zmwangx@…]

Well, all I can say is that it builds, and I didn't encounter any problems with a few test videos. I didn't go through all occurrences of the macro in the code base (and I doubt if I'm gonna understand the code), so I can't comment on whether there are side effects.

[dbevans (David B. Evans)]

Taking ffmpeg's word for it that bigger is better, mplayer2 input buffer padding size increased to 32 to match ffmpeg version 2.3 in r122337. Incremented revision to rebuild so everyone is using the same buffer size. As stated by reporter, this fixes building of mplayer2 with ffmpeg 2.3 and a few quick video tests show no obvious problems.

Thanks for the report.