[MPlayer-dev-eng] [PATCH] set is_streamed correctly in lavf URLContext

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Wed Dec 19 19:18:51 CET 2007


Hello,
On Wed, Dec 19, 2007 at 06:16:28PM +0200, Uoti Urpala wrote:
> On Wed, 2007-12-19 at 16:53 +0100, Reimar Döffinger wrote:
> > On Wed, Dec 19, 2007 at 05:18:54PM +0200, Uoti Urpala wrote:
> > > If you always require
> > > updating and installing FFmpeg just before compiling MPlayer, and always
> > > expect an existing MPlayer to break if you update FFmpeg (for another
> > > program) that makes shared libraries almost completely impractical.
> > 
> > Exactly. Nevertheless code that creates problems here is bad and should
> > be avoided anyway, so it should still work either way, but at least _I_
> > won't support such setups (I guess I was using "we" a bit hastily
> > before).
> 
> Supporting shared libraries with not exactly equal version basically
> means using FFmpeg functionality through the official API. You mean
> you're not willing to do that?

Define "public API". Neither the current code nor this patch use
anything that isn't in the installed headers AFAICT.

> Do you want to use "undocumented" ways to
> access things even when an official one exists?

Is that a different way of asking "are you an idiot"? Obviously not,
this not at all what I want. In case you haven't noticed, for this tiny
change alone two additions to the API seem to be necessary to do
something that is possible with the "public" API, but only in a
braindead way.

> Or think there will be
> things that cannot be done through the official API which you want to
> use for important functionality anyway (without adding them to the API)?

Possibly if adding them to the API is too much effort for me or not
acceptable due to other reasons.
But the point is simply I don't particularly enjoy wasting my time, so
why should I support (or even stop advising against) a setup that I know
is fragile, among other things because
1) MPlayer uses things from FFmpeg that are not part of the public API
2) FFmpeg has quite a few things in the public API that should not have
been there and are all too easy to misuse
3) Someone might forget to bump the FFmpeg version number
?
I think we can make the roots create a MPlayer-shared-libav list or
something like that if someone would like to support it, I'll happily
send everyone there instead of telling them to recompile with a matching
(preferably static) version...

Greetings,
Reimar Döffinger



More information about the MPlayer-dev-eng mailing list