[FFmpeg-devel] [PATCH] Fixed PNG decoding with Paeth filter for RGBA 64-bits.

[Dominique Leroux]

Hi Cristophe,

Before submitting yesterday evening, I pulled the latest changes from master and the problem is still present.

My situation happens with RGBA64.  The structure of the existing C code was meant to enter the optimized path with a buffer size that is compatible with SIMD constraints.  So I just generalized the buffer resizing so it takes any bpp into account (and not just bpp=3 or bpp=4 like before).

Here are sample files that are 4 lines long: the original and the corrupted output.  The corruption is on the rightmost edge, where last 3 lines have the expected pink replaced by yellow.

With my fix, the resulting output is as as the original.  The resulting file layout differs, however: the original has one single IDAT chunk for all 4 lines, whereas the output files have one IDAT chunk per line (hence the bigger size).  Maybe this is part of the reason it went unnoticed for so long as I don't think it is possible to generate such a png file with ffmpeg and the corruption does not happen on the first line.

Thanks for looking at this,

Dominique

-----Original Message-----
From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Christophe Gisquet
Sent: Friday, December 05, 2014 4:30 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Fixed PNG decoding with Paeth filter for RGBA 64-bits.

Hi,

2014-12-05 1:20 GMT+01:00 Dominique Leroux <Dominique.Leroux at autodesk.com>:
> Found and fixed an artifact in the last column of decoded RGBA 64-bits PNG images.
>
> The code was dealing with a SIMD-optimized version of the function without taking into account that we can have RGB/RGBA images that are respectively 6 or 8  bytes per pixel (not just 3 or 4).

First, what version are you working on? Ronald included a fix in http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=af79a0c48a41fd99b674b39ac509ae442974715d
that would then be incomplete?

If true, then it probably means we don't have a "fate" test for it (ie a means to validate ffmpeg's output against a known "good"
checksum/behaviour), or that it is unaffected by the bug.

In any case, could you share a sample file exhibiting the issue? I guess cropping to the last few lines would be fine from a quick glance at your patch. But I haven't studied the issue to actually validate it.

Thank you,
--
Christophe
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad_result_800x4_rgba64.png
Type: image/png
Size: 19578 bytes
Desc: bad_result_800x4_rgba64.png
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141205/beb48dd3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: original_800x4_rgba64.png
Type: image/png
Size: 9984 bytes
Desc: original_800x4_rgba64.png
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141205/beb48dd3/attachment-0001.png>