[Mjpeg-users] Bug Report: lav2wav memory leak
Version 1.8.0. Build on a Fedora Core 4 system with the enclosed .spec file. Tried only on .qt files generated with lavrec. lav2wav tries to eat up all available memory. When this succeeds it's killed by the system, thus leaving its job unfinished. See the following test: [EMAIL PROTECTED] tmp]$ cat test.eli LAV Edit List PAL 1 /home/benny/cam/tmp1/movie2969.qt 0 0 499 [EMAIL PROTECTED] tmp]$ [EMAIL PROTECTED] tmp]$ valgrind --leak-check=full lav2wav test.eli 20seconds.wav ==4195== Memcheck, a memory error detector for x86-linux. ==4195== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==4195== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==4195== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==4195== For more details, rerun with: -v ==4195== ==4195== Conditional jump or move depends on uninitialised value(s) ==4195==at 0x1BAC35DD: strstr (in /lib/libc-2.3.5.so) ==4195==by 0x1B9E4608: __pthread_initialize_minimal (in /lib/libpthread-2.3.5.so) ==4195==by 0x1B9E4237: (within /lib/libpthread-2.3.5.so) ==4195==by 0x1B9E3E23: (within /lib/libpthread-2.3.5.so) ==4195==by 0x1B8F0AF8: call_init (in /lib/ld-2.3.5.so) ==4195==by 0x1B8F0C15: _dl_init (in /lib/ld-2.3.5.so) ==4195==by 0x1B8E47CE: (within /lib/ld-2.3.5.so) ==4195== ==4195== Conditional jump or move depends on uninitialised value(s) ==4195==at 0x1BAC35E1: strstr (in /lib/libc-2.3.5.so) ==4195==by 0x1B9E4608: __pthread_initialize_minimal (in /lib/libpthread-2.3.5.so) ==4195==by 0x1B9E4237: (within /lib/libpthread-2.3.5.so) ==4195==by 0x1B9E3E23: (within /lib/libpthread-2.3.5.so) ==4195==by 0x1B8F0AF8: call_init (in /lib/ld-2.3.5.so) ==4195==by 0x1B8F0C15: _dl_init (in /lib/ld-2.3.5.so) ==4195==by 0x1B8E47CE: (within /lib/ld-2.3.5.so) INFO: [lav2wav] WAV done ==4195== ==4195== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 44 from 1) ==4195== malloc/free: in use at exit: 11961031 bytes in 1055 blocks. ==4195== malloc/free: 2631 allocs, 1576 frees, 20213235 bytes allocated. ==4195== For counts of detected errors, rerun with: -v ==4195== searching for pointers to 1055 not-freed blocks. ==4195== checked 9566896 bytes. ==4195== ==4195== ==4195== 2017280 bytes in 394 blocks are possibly lost in loss record 38 of 40 ==4195==at 0x1B907222: malloc (vg_replace_malloc.c:130) ==4195==by 0x1B9332DD: lav_read_audio (lav_io.c:840) ==4195==by 0x1B931B98: el_get_audio_data (editlist.c:484) ==4195==by 0x8049154: main (lav2wav.c:368) ==4195== ==4195== ==4195== 3102720 bytes in 606 blocks are definitely lost in loss record 40 of 40 ==4195==at 0x1B907222: malloc (vg_replace_malloc.c:130) ==4195==by 0x1B9332DD: lav_read_audio (lav_io.c:840) ==4195==by 0x1B931B98: el_get_audio_data (editlist.c:484) ==4195==by 0x8049154: main (lav2wav.c:368) ==4195== ==4195== LEAK SUMMARY: ==4195==definitely lost: 3102720 bytes in 606 blocks. ==4195== possibly lost: 2017280 bytes in 394 blocks. ==4195==still reachable: 6841031 bytes in 55 blocks. ==4195== suppressed: 0 bytes in 0 blocks. ==4195== Reachable blocks (those to which a pointer was found) are not shown. ==4195== To see them, rerun with: --show-reachable=yes [EMAIL PROTECTED] tmp]$ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] Re: Mplex lpcm bug+fix (1.8.0)
Hi again, just ran across an audio test disk with a comprehensive set of lpcm varieties at http://www.videohelp.com/~jsoto/AudioTests/ No information on what tool was used to author the tracks, but the payloads appear to be: LPCM TYPE : payload Multichannel: VTS04: LPCM 16 bits 5.1 : 1992 (multiple of 24*) VTS05: LPCM 20 bits 5.1 : 2010 (multiple of 30) LPCM 96 KHz: VTS13: LPCM MONO 96k 16bits : 2008 (multiple of 4*) VTS14: LPCM MONO 96k 20bits : 2010 (multiple of 5) VTS15: LPCM MONO 96k 24bits : 2010 (multiple of 6) VTS16: LPCM STER 96k 16bits : 2008 (multiple of 4,8) VTS17: LPCM STER 96k 20bits : 2010 (multiple of 10) VTS18: LPCM STER 96k 24bits : 2004 (multiple of 12) (* Don't understand why these aren't 12 2; the payloads would be 2004 2010, and still fit) I didn't burn the disc, but videolan player, which so far has behaved exactly the same as my Philips player, plays the vob files, though strangely the 20 and 24 bit mono tracks are hissy. Based on the above, whole_unit = channels * bits_per_sample / 4; seems to fit all cases. regards, Bahman __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Bug Report: lav2wav memory leak
On Wed, 12 Oct 2005, Benny With wrote: Version 1.8.0. Build on a Fedora Core 4 system with the enclosed .spec file. Tried only on .qt files generated with lavrec. .qt will be going away in the future. Now would be a good time to begin the habit of using the more standard .mov extension. At one time there was a container format called movtar which used the .mov extension so Quicktime began using .qt. Movtar was removed ages ago and beginning with the current CVS version of mjpegtools .mov is used for Quicktime (just like the Quicktime movies on the Internet). lav2wav tries to eat up all available memory. When this succeeds it's killed by the system, thus leaving its job unfinished. Try the attached patch. Or wait a couple hours and it will be available via anonymous cvs. The bug was introduced when the byte swapping code was added (on big endian systems it's necessary to put the data into little endian byte order). It's pretty obvious that 'i' is not properly set up for the loop anyhow :( Cheers, Steven Schultz --- lav_io.c.dist 2005-10-10 10:46:50.0 -0700 +++ lav_io.c2005-10-13 09:06:48.0 -0700 @@ -878,10 +878,9 @@ } out: for (j = 0; j channels; j++) -qt_audio[(channels*i) + j] = qt_audion[j][i]; - -free(qt_audion); - return(res); +free(qt_audion[j]); + free(qt_audion); +return(res); #endif } return -1;
Re: [Mjpeg-users] Re: Mplex lpcm bug+fix (1.8.0)
On Thu, 13 Oct 2005, bn wrote: just ran across an audio test disk with a comprehensive set of lpcm varieties at http://www.videohelp.com/~jsoto/AudioTests/ ... Based on the above, whole_unit = channels * bits_per_sample / 4; Ah, nice and simple and covers all known cases. The change has been checked in to cvs. Cheers, Steven Schultz --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
