[MPlayer-dev-eng] [PATCH] Add giflib 5 support

Andïï gnu.andrew.rocks at gmail.com
Sat May 4 21:47:45 CEST 2013


On May 4, 2013 6:52 PM, "Reimar Döffinger" <Reimar.Doeffinger at gmx.de> wrote:
>
> On 04.05.2013, at 19:21, Andïï <gnu.andrew.rocks at gmail.com> wrote:
> > On May 4, 2013 7:34 AM, "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
wrote:
> >>
> >> On 02.05.2013, at 11:50, Andrew John Hughes <gnu_andrew at member.fsf.org>
> > wrote:
> >>
> >>> Trying again...
> >
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2013-April/071595.html
> >>>
> >>> The attached patch allows mplayer to be built with giflib 5.  Tested
> >>> against 1.1 and SVN.
> >>
> >> Sorry, I forgot to ask a few things.
> >> I was wondering if there is much "need" for it, since FFmpeg does
support
> > gif quite fully I think. Basically I am curious why you care :-)
> >
> > If giflib has been upgraded to version 5, mplayer won't even detect the
> > presence of giflib and support won't be compiled. The patch fixes
configure
> > to detect version 5 too, and the consequent build errors from code.
>
> So far it's obvious, but who cares if giflib is enabled or not.
>

People who use it?  I assume there's some userbase for it or you'd have
just removed it from the codebase altogether.

> >> This is related to whether there is much of a point in keeping support
> > for the old version.
> >
> > Support for <5 needs to be kept for those who haven't yet upgraded.
>
> I see no obvious "need", we can just drop support for it.
> I wanted to know what reasons there are to continue to support versions <
4.
> Since I consider our giflib support fairly pointless (less relevant than
aalib even for example) there should be a fairly good reason to add to the
maintenance burden by keeping support for old versions instead of telling
users "upgrade if you really need it".

Fair enough.  The patch was originally written for the existing 1.1 so
there are different considerations than if you're doing a new release where
you can say "giflib needs version 5 or later".

It would certainly simplify the patch.

> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng


More information about the MPlayer-dev-eng mailing list