[FFmpeg-devel] [PATCH] Fixed CamStudio decoder picture corruptions

[Reimar Döffinger]

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.