Bug#732159: Should this package be removed?

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Feb 19 18:58:28 UTC 2014


On Wed, Feb 19, 2014 at 08:24:01AM -0500, Reinhard Tartler wrote:
> TBH, I'm a bit confused about your reply.

I probably lost track of the point I was trying to make.
I so far assumed that this issue was, bluntly put, about
almost exclusively
1) MPlayer does not work against Libav

But what you wrote sounded more like it's at least also
2) MPlayer has packaging issues

I've mentioned this a few times over the years, I'd be interested in
improving 2), and that is regardless of the status of this ticket.

> On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > 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.
> 
> I take this as that you (as upstream) do not want mplayer to be
> compiled against libav.

No it means "I feel unable to maintain support for that".
And that is the same situation as right after the fork,
nobody has stepped up since then to take on this task.
(Yes, I am well aware that the mailing list climate was not
helpful in attracting someone to do it, and I am sorry for that).

> Besides, has development and support for mencoder been revived, or do
> its developers still consider mencoder deprecated and/or obsolete?

It's still on basic life support. So I don't think it should be considered
a major concern.
Still, ffmpeg/avconv in some cases still can't 100% replace it,
especially if it's not the very latest of those, so I am of course
still interested in not letting any users hang if there was some
magic easy way to achieve it.

> >> 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.
> 
> Sorry, but taking mplayer as political argument to make pressure on
> the FFmpeg vs. Libav conflict is not going to help anyone. Please have
> this discussion elsewhere, e.g. in  #729203.

This was not mean political, this is about "solving" my point 1) above.
If we agree that we see no way to solve/avoid that I think there is
no point in dragging this out any further.

> >> 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.
> 
> I missed that, did that change recently?

I don't think so. I think it must have been like this at least a year,
but no promises.
I do not know if Debian might have used options like --enable-zr (that
is the part that now no longer compiles), that one had hooks deep
into FFmpeg, but I think it lost what little relevance it had years ago.

> > 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.
> 
> Well, if it was really only two (internal!) headers that it takes, why
> doesn't mplayer embed them just like mplayer2 and mpv, and just ditch
> the svn:external equivalent for git mechanism? This needs to be
> disabled when packaging it for use with a system-provided libavcodec
> anyways.

If I make a copy of them I become responsible to maintain/update them.
Which I'd only want to do if it's really the best solution to a
significant problem.
Plus, creating a ffmpeg/ directory automatically disables the
automated FFmpeg download, so solving the one also fixes the other for
you.

> Nevertheless, if what you say is true, then current mplayer should be
> indeed rather easy to compile against any copy of libavcodec.

I expect there will be rough edges still, it's poorly tested.
It's a long progress, and at the risk of offending from my point of
view in part due to an unwillingness from the side of package
maintainers to complain loudly and clearly.

> > 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...
> 
> Are they critical for Debian?
> 
> I personally don't think so, because I don't consider the missing
> functionality that important.

I don't know. I admit I am mostly thinking of VDPAU, though obviously
Ubuntu decided that saving 8.3 MB of disk space is more important than
it, so I might grossly overestimate its importance.
First of all, it would need to build at all however, and then someone
needs to ensure it continues to do so.
And someone should at least do some testing.
I hope you understand that at this point I consider it just too much.

> If it was, then it could be fixed if there was enough good will.

I so far assumed that even with good will the manpower wouldn't be
there.

> However, the political pressure and the
> constant nagging from both developers and spectators result in a very
> aggressive and negative atmosphere, and thus has diminished my
> motivation to continue working on the package significantly.

I know, and not only yours, and sorry.

> I mean,
> even you as one of last very active mplayer developers use terms such
> as "cripple" to induce political pressure towards FFmpeg.

There is probably more truth in it than I'd like to admit,
but I still believe I mostly meant it as a short-hand for
"there will be compatibility issues (or if you want, MPlayer code
horriblyness to not start a discussion on who is to blame) for
which I see no easy/quick solution that does not involve losing functionality".

> >> > 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 don't think users need to know the political background behind all
> of this. Since we adopted that policy and explanation, the number of
> bug reports of applications that link against libavcodec with crashes
> that stem from libraries that interfere here significantly decreased.

But the details are kind of relevant here, since its MPlayer/mencoder
packages do not depend on libavcodec packages...
If you want me to stop arguing about this, just tell me so, but as
long as you bring counterarguments I'll argue if they don't convince me.



More information about the pkg-multimedia-maintainers mailing list