Hi, On Monday 24 November 2003 18.16, you wrote: > On Mon, 24 Nov 2003, Michael Hanke wrote: > > Thanks a lot for all of your help. I had to upgrade libtool and autoconf. > > Then the build went smoothly. But when I tried yuvdenoise, I got an > > memory > In utils/cpu_accel.c you should see the function bufalloc() which > is where the malloc error is coming from. The only thing I can > think of to try is add a "fprintf(stderr, "size = %d\n", size);" > at the beginning to see if a bogus request size is being passed > in. I did it. The request size is moderate: 450560. So need to have a closer look at the problem. For tracing down memory allocations, is it possible to link against dmalloc or ElectricFence? Will this have an effect on posix_memalign?
Another possibility: With reference to http://sources.redhat.com/ml/bug-glibc/2002-09/msg00037.html, http://sources.redhat.com/ml/bug-glibc/2002-06/msg00202.html maybe there is a bug in glibc?? Did you use posix_memalign in version 1.6.1? > > > [EMAIL PROTECTED]:/usr/local/xcdroast/MJPEG > lav2yuv final01.eli |yuvdenoise > > | y4mscaler -I active=692x564+8+4 -S option=cubicCR -O preset=svcd | > > yuvplay > > The vertical dimension/offset really must be a multiple of 4 for > interlaced material (multiple of 2 per field but there are 2 > fields). All input dimensions are a multiple of 4! The cause of the problem is probably the reallocation in the output stream. Here, I left all decisions to y4mscaler. Michael ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
