Re: Fix for memory corruption in yuvdeinterlace

Burkhard Plaum <[email protected]> Fri, 12 Oct 2007 16:11:55 +0200
Newsgroups gmane.comp.video.mjpeg.devel
Message-ID <[email protected]>
Hi,

Steven M. Schultz schrieb:
> 	It just feels "sloppy" to over allocate the buffers rather than 
> 	check for the boundary conditions.  Why not allocate the exact 
> 	size needed and check the address so that it doesn't go outside
> 	the frame?

For speed reasons. What we have here, is basically an FIR filter, which
does something like:

dst[i] =
   coeff_1 * src[i-1] +
   coeff_2 * src[i] +
   coeff_3 * src[i+1];

That's a 3-tap filter, the number in yuvdeinterlace is larger.
Boundary cases are normally handled by effectively doing
(e.g. for i = 0):

dst[i] =
   (coeff_1 + coeff_2) * src[i] +
   coeff_3 * src[i+1];

This means, that pixels beyond the border are assumed to be identical to the
border pixels.

Now if one handles the boundary cases specially, the code becomes bloated and
less readable. If one checks for overshots within the innermost loop, the code
becomes slower due do to 2 additional if()s.

Exactly the same problem occurs, if we scale video or resample audio.

In gavl, I'm doing something like

dst[i] =
   coeff_1 * src[src_indices[i][0]] +
   coeff_2 * src[src_indices[i][1]] +
   coeff_3 * src[src_indices[i][2]];

where the src_indices array is initialized at the beginning and never
overshoots. Over-allocating is another possibility (not sure if it's the better
one).

Burkhard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/