Post by Philipp StannerOk, great to know :)
But some codecs are supported natively without linking to other
libraries? Thinking about it this way I wonder why anyone would
support codecs natively in any case, as you can just link to the
responsible libs.
Short answer: historical reasons.
IIRC, this was partly because in some cases there *weren't* originally
any libraries available (for the relevant platforms) which supported the
codecs in question, and in others someone thought the available library
didn't do the job well enough and thought they could do better.
Of course, if you're going to try to implement codec (etc.) support
better, it would make more sense to do it in a library than in MPlayer
itself, so that it can be used by other software - and, if I'm not
mistaken, that's exactly why so many codecs (etc.) got implemented in
FFmpeg rather than natively within MPlayer.
If all you want is to have MPlayer support the codec, it's very probably
faster and easier to implement the codec within MPlayer than to write a
separate library and then implement MPlayer support for that library.
But it's probably even faster and easier than *that* to implement the
codec within FFmpeg (which MPlayer already supports) and then let
MPlayer pick it up automagically - and doing that means other software,
beyond just MPlayer, can get the new codec automagically as well.
About the only reason to do it as an independent library nowadays, that
I can think of offhand, is if you don't want to deal with getting it
accepted into FFmpeg (and/or don't want to live within the constraints
of the FFmpeg structure).
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw