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/