[MPlayer-dev-eng] Allow compilation with Libav

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Jan 3 02:04:23 CET 2012


On 2 Jan 2012, at 19:34, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le tridi 13 nivôse, an CCXX, Reinhard Tartler a écrit :
>> As for the ffmpeg/libav politics, let's please leave them aside for now
>> and focus on the following patch:
> 
> Yes, of course.
> 
>> In my tests, this allows compilation against libav. Moreover, this
>> version does allow mplayer to playback escape130 files when compiled
>> against FFmpeg.
> 
> It will not allow a mplayer built against a libav tree and dynamically
> linked to lavc to start playing escape130 if lavc.so is replaced by one
> coming from ffmpeg, but I believe we can live with that for now.
> 
> If Reimar is fine with the ifdeffery -- I know he does not like it as a
> general principle -- this patch seems ok.

I do not like it, yes. I can accept it, but that is only if it's not completely broken.
The current suggestions are, the decoder config defines are not part of the public API and won't work when compiling against external FFmpeg.
You can just distinguish between FFmpeg and libav by checking whether the micro version is < 100 (there might be some other method preferred libav-side).
Of course this means that these codecs will not be supported with libav even if support for them is added there.
As said before I am not willing to make an effort to support libav myself (ok, not much of an effort, I guess I am too nice to make no effort at all), so I'd request for someone else to keep an eye out for that (or come up with a better solution).
One possible solution might be to make the mapping codec name <-> tag and then use a find codec by id etc.
However this has a few issues, too. For example we will want some/most mappings to work even when lavc was compiled without support for that codec.
Also in the past against my objections the name was not considered part of the ABI, so this might break any time even without a major bump.
Thuse so far my best idea is a hard-codec check for FFmpeg vs. libav, crappy as it is.


More information about the MPlayer-dev-eng mailing list