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-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@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.ler...@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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
