There was exactly one gstffmpegcolorspace change between 0.10.12 and 0.10.13:

        * gst/ffmpegcolorspace/gstffmpegcolorspace.c:
        (gst_ffmpegcsp_transform):
        * gst/videoscale/gstvideoscale.c: (gst_video_scale_transform):
        Basetransform copied the metadata for us.

I don't think that's what did it... Similarly, there doesn't look to be anything suspicious in pngdec's changelog. 

From the log, I suspect the problem is actually triggered by the acceptcaps changes that happened in core...

So, the problem is triggered by the acceptcaps changes in core, but caused by a mismatch in the pad caps pngdec uses for RGBA versus ffmpegcolorspace:

/pipeline0/pngdec0.src: caps = video/x-raw-rgb, width=(int)1501, height=(int)391, bpp=(int)32, framerate=(fraction)0/1, depth=(int)32, endianness=(int)4321, red_mask=(int)-16777216, green_mask=(int)16711680, blue_mask=(int)65280, alpha_mask=(int)255

This is "RGBA"

ffmpegcolorspace has:

      video/x-raw-rgb
                  width: [ 1, 2147483647 ]
                 height: [ 1, 2147483647 ]
              framerate: [ 0/1, 2147483647/1 ]
                    bpp: 32
                  depth: 32
               red_mask: 65280
             green_mask: 16711680
              blue_mask: -16777216
             alpha_mask: 255
             endianness: 4321

which is "BGRA".

If I hack ffmpegcolorspace to have the same masks as pngdec, it produces the attached image as output which is obviously not correct but seems to have the right colours, implying that the pngdec masks are right, and ffmpegcolorspace's are currently not, we just never noticed because it was accepting the caps anyway?

Created attachment 90884 [details]
screenshot of the converted output.

This screenshot is made using ximagesink, but xvimagesink and a YUV conversion produces the same result.

With the same hack, gdkpixbufdec produces output with R & B swapped for that file.

Something is wrong with our RGBA caps descriptions, but I can't remember how they're supposed to work, so I don't know what.

ffmpeg has this:

PIX_FMT_RGBA32: layout in memory on LE : B G R A 
PIX_FMT_RGBA32: layout in memory on BE : A R G B

PIX_FMT_BGRA32: layout in memory on LE:  A R G B 
PIX_FMT_BGRA32: layout in memory on BE:  B G R A

there is no format describing R G B A on any architecture, pngdec cannot be linked. 

Fixed in CVS:

2007-07-06  Jan Schmidt  <thaytan@mad.scientist.com>

        * gst/ffmpegcolorspace/avcodec.h:
        * gst/ffmpegcolorspace/gstffmpegcodecmap.c:
        (gst_ffmpeg_pixfmt_to_caps), (gst_ffmpeg_caps_to_pixfmt),
        (gst_ffmpegcsp_avpicture_fill):
        * gst/ffmpegcolorspace/imgconvert.c: (img_convert),
        (img_get_alpha_info):
        Add 2 new pixel formats - ABGR32 and ARGB32, which are reflections
        of the existing BGRA32 and RGBA32 formats with the alpha at the other
        end of the word. Partially fixes #451908

and the sister commit in -good:

2007-07-06  Jan Schmidt  <thaytan@mad.scientist.com>

        * ext/libpng/gstpngdec.c: (gst_pngdec_caps_create_and_set):
        Remove endianness-flipping hack that seems to have been required
        only because of a bug in ffmpegcolorspace.
        Partially Fixes: #451908