[MPlayer-dev-eng] [PATCH] bugfix vo_png vo_gif89a

Joey Parrish joey at yunamusic.com
Mon May 13 12:56:07 CEST 2002


Hello,

Attached are two patches, one for vo_png, one for vo_gif89a.


The bugs in vo_png are:
  - bad colorspace conversion for I420
    (found with ftp://ftp.mplayerhq.hu/MPlayer/samples/testsuite/i263.avi)
  - segfaults when converting from 32 to 24 bit color
    (found after removing I420 support from vo_png [with the same video])

I fixed this by disabling both I420 and RGB32 support in vo_png.  MPlayer now
converts the colorspace properly before sending it to vo_png.


The bugs in vo_gif89a are:
  - the same bugs listed in vo_png above
    (since gif89a used much of the same code)
  - some versions of libgif/libungif are buggy or do not have full support
  - i think libgif should be the preferred choice by configure over libungif
  - had no subtitle support

I removed support for RGB32, BGR32, I420, IYUV.  Colorspaces work right now.
Added a check to configure to try to determine if your version of libgif/libungif
is too old.  This is to stop two problems: old versions (pre v4) could not do
more than one control block (meaning loop extension kept vo_gif89a from linking).
Some more recent versions will do this but the (very normal) EGifSetGifVersion
call causes segfaults.  I check for both of these in configure, if either or both
are problems, then the loop extension is disabled and the GIF header will say 87a.
(Most browsers don't actually care about the GIF version header.)  Added subtitle
support (borrowed code from other vo_'s.)

As for preferring libgif over libungif, I know this might cause some concern about
the use of LZW compression.
It's not a problem to make use of it if a user already has the library, right?
Wouldn't this be similar to not including decss but writing optional support for it?
The two libraries are API compatible and vo_gif89a is ignorant of whether the
output is compressed or not.  It's all done internally by the library.  Besides, if
a user  has the compressed GIF library available, it's probably because they want to 
make use of it.  If they don't have it, or if it's a symlink to libungif (as many
are), then libungif is used anyway.
Anybody else have any comments, corrections, or input on this?

Problems I've found but not patched yet:
  - vop scale with gif89a causes crashes

Thanks, everyone.
--Joey

-- 

"Yes." -- John F. Kennedy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: png_fix.diff
Type: x/diff
Size: 1817 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020513/36ad98de/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gif_fix.diff
Type: x/diff
Size: 5722 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020513/36ad98de/attachment-0001.bin>


More information about the MPlayer-dev-eng mailing list