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

[Uoti Urpala]

On Wed, 2007-12-19 at 19:18 +0100, Reimar Döffinger wrote:
> > 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.

The part that is intended to be used by other programs. If the struct is
in the public headers but it's not clear that it is not intended to stay
identical even over minor version changes then that is a problem in
FFmpeg.

> > 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.

The basic functionality of demux_lavf is something that should be doable
using the public API. If it is not that is a clear deficiency in FFmpeg.
If you don't want to improve FFmpeg yourself that's fine of course; but
having to work around the public API is a clear "should be fixed by
someone" problem, and so I think "we make no effort to stick to the API"
is not good as a general policy.

> > 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

Supporting it doesn't require much more than using the public API, and I
consider using that where possible to be beneficial even if you don't
care about shared libraries specifically.

> is fragile, among other things because
> 1) MPlayer uses things from FFmpeg that are not part of the public API

Yes, but the number of those is limited and other people seem to
maintain them.

> 2) FFmpeg has quite a few things in the public API that should not have
> been there and are all too easy to misuse

If such misuse is spotted it should be fixed.

> 3) Someone might forget to bump the FFmpeg version number

Might happen, but I don't think it would be that much more common than
other unrelated problems with the code.

> 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...

I think there shouldn't be that many problems specific to shared
libraries in MPlayer code. There could be "FFmpeg API sucks" problems,
but we already have ffmpeg-dev for those...

If you think the FFmpeg API is so unreliable at the moment that users
should be advised to avoid shared libraries for now then I don't oppose
that; but I think that is no reason not to try writing MPlayer code in a
way that uses the public API and is compatible with shared libraries.