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 :
> 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