[FFmpeg-devel] [PATCH] Fixed CamStudio decoder picture corruptions
Reimar Döffinger
Reimar.Doeffinger
Sat Oct 30 18:53:01 CEST 2010
On Sat, Oct 30, 2010 at 05:18:38PM +0200, Laurent Aimar wrote:
> I have checked with the code source of CamStudio, it always pads to 4
> regardless of the chroma:
>
> DWORD CodecInst::CompressRGB(ICCOMPRESS* icinfo)
> {
> [...]
> int remainder = icinfo->lpbiInput->biWidth % 4;--
> if (remainder > 0)
> {
> int newbit = icinfo->lpbiInput->biBitCount;
>
> // In the original version, remainder was subtracted from newwidth.
> // This is wrong - it causes a black line to appear over the video
> // if the width's not divisible by 4, so it's been removed.
> int newwidth = icinfo->lpbiInput->biWidth;
> int newheight = icinfo->lpbiInput->biHeight;>-----
> int wLineLen = (newwidth * (newbit) + 31) / 32 * 4;
> int newsize = wLineLen * newheight;>-->---
>
> input = (unsigned char*)icinfo->lpInput;-->---
>
> // strange, adding this line will allow the image to be displayed!!
> in_len = newsize;
> }
> else // normal case
> {
> input = (unsigned char*)icinfo->lpInput;--
> in_len=icinfo->lpbiInput->biSizeImage;
> }
> [...]
> }
>
> but I don't have any 16 bits sample to confirm it is actually needed.
I'm pretty sure you won't find any.
This is the compress function which takes a bitmap from Windows and
compresses it, and I am quite conviced above code does not work at all for
odd-width 16 bpp images (in contrast to 24 bpp there is no issue for width
% 4 == 2 for 16 bpp).
> The sample I have is 24 bits:
> http://trac.videolan.org/vlc/attachment/ticket/3778/example.zip
My patch is applied and of course fixes that one.
More information about the ffmpeg-devel
mailing list