[gstreamer-bugs] [Bug 163177] New: [pngdec] Can't cope with png's without an alpha channel

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=163177
 GStreamer | gst-plugins | Ver: HEAD CVS

           Summary: [pngdec] Can't cope with png's without an alpha channel
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: algernon at bonehunter.rulez.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


Grab a png without an alpha channel, and decode it with pngdec, then re-encode
it with pngenc, and observe that the result is somewhat disappointing.

Problem lies in ext/libpng/gstpngdec.c, function gst_pngdec_chain, near the end,
where the code reads:

  inp = GST_BUFFER_DATA (out);
  for (i = 0; i < height; i++) {
    rows[i] = inp;
    inp += width * 4;
  }

That assumes that the thing is 32 bits wide, when it isn't. It is only 24.
Two solutions exist: first, force libpng to add a dummy alpha channel
(PNG_TRANSFORM_EXPAND flag, iirc), or to use pngdec->bpp / depth instead of that
hard-coded 4.

I can supply a patch for any of those (for now, I did the pngdec->bpp / depth
thing, that one is more memory friendly, and pngdec only supports 8 bpp RGB+RGBA
stuff now anyway).

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.