Bug#732159: Should this package be removed?

[Reimar Döffinger]

On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > What would constitute a constructive comment?
> 
> Ideally "I am interested in making mplayer work against the libavcodec
> that we have in Debian, and this is my work in progress".

Well, I expect that making it build wouldn't be that hard, but it
would be quite crippled and broken, and with the limited effort I
am willing to spend on getting patches into Libav I won't be getting
anywhere I would conclude from previous tries.

> > mplayer2 is unmaintained and as far as I can tell mpv has completely
> > different command-line syntax at the least (though I am not well
> > informed about either).
> 
> It was my sincere hope that this would be a sufficient incentive and
> motivation to work on keeping mplayer/mencoder in debian.
> Unfortunately, it seems I was wrong.

Well, it was motivation to suggest several ways to get FFmpeg into
Debian, since that is kind of the most realistic way to solve it,
also since otherwise it won't be the version of MPlayer that
is tested upstream.
However so far this seems to be considered completely out of the
question.
Which for me kind of leaves the question if the best MPlayer we
can offer under these circumstances is worth it.

> > Libav compatibility is not intentionally broken upstream, but it
> > is not tested in any systematic way either (possibly not at all).
> 
> This is not the primary concern or reason in the context of whether or
> not to remove mplayer/mencoder from Debian. The reason is that there
> is nobody who is interested enough to work on making it suitable in
> Debian. Otherwise we wouldn't have to remove the package from
> Debian/testing (jessie).

This sounds to me like you see a difference between "Libav
compatibility" and "suitable in Debian"?
I'd be interested in that.

> Personal remark here: mplayer was always problematic in Debian. Up to
> today, it is not possible to even compile mplayer without removing its
> internal copy of ffmpeg.

Yes, no, maybe. I just looked into it. You have to provide matching
copies of libavformat/internal.h (can be eliminated reasonably well if
it's a concern) and libavutil/x86/asm.h (only issue here is that I don't
like duplicating it).
Nothing else is required.

> This was only acceptable because I made sure
> that its internal copy is only used at build-time, allowing mplayer to
> access internal functionality that is not part of the public API.

As far as I can tell none of that internal API usage remains,
unless you enable certain special features like those old
JPEG decoder cards (that actually don't compile anymore
even against internal FFmpeg).

> This
> makes maintaining mplayer in Debian much more challenging, and
> basically means that mplayer and libav always need to be updated in
> lockstep.

This has not been the case for some time.
Well, at least not due to internal API usage.
I believe there are a few "accessor" functions that MPlayer does not use when it
should, but that's kind of a bug.

> It is true that for quite some time I used my mplayer svn
> commit privileges to make it possible to use libav instead of ffmpeg
> as internal copy. I stopped doing this work, mainly because I felt
> that these kind of work is not welcome inside mplayer.

Well, "welcome" it is maybe from everyone's standpoint, but
even some of the developers who welcome it least have added ifdefs
to avoid breaking it even further.

> Actually, I would be very interested in that, but not before
> there was some mplayer release that stopped requiring an internal copy
> of libav*

I haven't tested the last release, and I don't know if only
requiring these two headers I mentioned is good enough,
but I would say it doesn't require an internal copy anymore.
I even fixed configure so that if you have only those two files
in ffmpeg/... it will default to compiling against a system FFmpeg.
Making a new release is something that would be good to do anyway.
_However_ none of this fixes the FFmpeg vs. Libav issues...

> > Now, deb-multimedia.org provides it anyway so it won't leave people
> > completely stranded, but I wonder if maybe there was a way to
> > somehow point people there when they try something like
> > "apt-get install mencoder"?
> 
> I disagree that deb-multimedia.org is actually helping here. I would
> rather recommend people that want to use mencoder on Debian to just
> follow upstream's recommendation: compile it yourself, and statically
> link against its internal copy of libavcodec.

This is kind of messy on non-developer machines where it involves
installing compilers an lots of -dev packages, plus not knowing which
are needed (I suspect the debian packaging scripts inside the MPlayer
source are thoroughly broken at this point, though I have not tried).

> > I can see why you might have some concerns with that, but it would
> > seem like a kind of user-friendly solution to me that doesn't
> > require much effort from anyone...
> 
> I don't share this understanding of "user-friendly". (cf.
> https://wiki.debian.org/DebianMultimedia/FAQ#A_recent_upgrade_of_ffmpeg.2Flibav-related_library_packages_.28e.g._libavcodec.29_has_broken_related_software_.28e.g._Totem.2C_MPlayer.2C_VLC.2C_Xine.29)

This is too light on details to know what was going on.
I am sure that adding deb-multimedia in a way that will select
it by default can cause pain, however picking _only_ mencoder
and any of its dependencies not in Debian I think should
not be able to cause this kind of issue.
It _might_ even be possible to just download and manually install the
mencoder packages from there.
Just to be clear, this is just some wild thinking, not anything
I seriously propose at this point.

Regards,
Reimar Döffinger