Quoting "Steven M. Schultz" <[EMAIL PROTECTED]>:
> But even after doing that there is the same type of error that
> was found in yuvdeinterlace.
OK, so I will drop in here... :-)
All buffers in yuvdeinterlace, yuvdenoise and most probably
yuvmotionfps (as it is based on an old yuvdeinterlace-version *need*
*far* bigger buffers.
> There is a HUGE difference between:
>
> nframe[0] = buff_offset + (uint8_t *) bufalloc (buff_size);
>
> and
>
> inframe[0] = (uint8_t *) bufalloc (buff_offset + buff_size);
>
> The FIRST one is what was being done. It allocates a buffer of
> buff_size bytes and THEN modifies the pointer.
And that one was correct as buffsize was modified *before* to be
bigger. buff_size was added with the size of some lines above and
below the buffer. As the functions all rely on a pointer pointing
*inside* the buffer to the beginning of the data, the first line was
correct for yuvdeinterlace.
Steven, your malloc-bugfix introduced that bug...
// before the bugfix...
// code fragment (Revision 1.9 yuvdeinterlace.cc):
//-------------------------------------------------------------
void initialize_memory (int w, int h, int cw, int ch)
{
int luma_size;
int chroma_size;
// Some functions need some vertical overshoot area
// above and below the image. So we make the buffer
// a little bigger...
vertical_overshot_luma = 32*w;
vertical_overshot_chroma = 32*cw;
luma_size = ( w * h ) + 2 * vertical_overshot_luma;
chroma_size = ( cw * ch ) + 2 * vertical_overshot_chroma;
inframe[0] = (uint8_t *) malloc (luma_size) + vertical_overshot_luma;
inframe[1] = (uint8_t *) malloc (chroma_size) + vertical_overshot_chroma;
inframe[2] = (uint8_t *) malloc (chroma_size) + vertical_overshot_chroma;
...
...
...
}
~deinterlacer ()
{
int vertical_overshot_luma = 32*YUVdeint.width;
int vertical_overshot_chroma = 32*YUVdeint.cwidth;
free (inframe[0] - vertical_overshot_luma);
free (inframe[1] - vertical_overshot_chroma);
free (inframe[2] - vertical_overshot_chroma);
...
...
...
}
//-------------------------------------------------------------
This worked as follows:
The plain image-planes need a size of just w*h. As some functions
dramaticaly overshot (eg. the MC-functions, ELA and
antialiasing-filters...) by far more than just 1 or 2 lines of pixels,
a save-area is defined of 32 lines top of and below of the buffer. So
the buffer-size is increased by two times vertical_overshot. *But* to
make this work, it is absolutly required, that the pointer is shifted,
so it points *inside* the allocated memory and not to the beginnig of
it...
This is the code *after* your "bugfix":
// code fragment (Revision 1.0 yuvdeinterlace.cc):
//-------------------------------------------------------------
void initialize_memory (int w, int h, int cw, int ch)
{
int luma_size;
int chroma_size;
// Some functions need some vertical overshoot area
// above and below the image. So we make the buffer
// a little bigger...
vertical_overshot_luma = 32*w;
vertical_overshot_chroma = 32*cw;
luma_size = ( w * h ) + 2 * vertical_overshot_luma;
chroma_size = ( cw * ch ) + 2 * vertical_overshot_chroma;
inframe[0] = (uint8_t *) malloc (luma_size + vertical_overshot_luma);
inframe[1] = (uint8_t *) malloc (chroma_size + vertical_overshot_chroma);
inframe[2] = (uint8_t *) malloc (chroma_size + vertical_overshot_chroma);
...
...
...
}
~deinterlacer ()
{
free (inframe[0]);
free (inframe[1]);
free (inframe[2]);
...
...
...
}
//-------------------------------------------------------------
This makes the buffers even bigger than than in 1.9, but the pointer
is directing to the *beginning* of the malloced area. This make every
single function which need the overshot barf on machines with strict
memory-protection as they *will* now try to access memory outside of
the buffer...
> There is a HUGE difference between:
You are right. There *is* a big difference between these two...
:-))))) Could you please fix your fix?
cu
Stefan
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
