Re: Malloc failed, Was: Re: [Mjpeg-users] MPEG2 encoding performance
On Wed, 26 Nov 2003, Michael Hanke wrote: Hi! 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); I did it. The request size is moderate: 450560. So need to have a closer look Quite reasonable size so there must be something else causing malloc() to return NULL. 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? It should be possible. The easiest way to do that I think is edit the generated Makefile to add the necessary libraries. 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? Use of posix_memalign is a recent addition to mjpegtools and was not used in earlier versions of mjpegtools. Ah, it could well be a glibc bug. What happens if you change posix_memalign to simply be malloc()? If that works then that would be evidence of a glibc bug. | y4mscaler -I active=692x564+8+4 -S option=cubicCR -O preset=svcd | All input dimensions are a multiple of 4! The cause of the problem is probably And so they are - my mentall 'bc' had a fault that night ;) Cheers, Steven Schultz --- 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
Fwd: Malloc failed, Was: Re: [Mjpeg-users] MPEG2 encoding performance
-- Forwarded Message -- Subject: Malloc failed, Was: Re: [Mjpeg-users] MPEG2 encoding performance Date: Mon, 24 Nov 2003 08:32:35 +0100 From: Michael Hanke [EMAIL PROTECTED] To: Steven M. Schultz [EMAIL PROTECTED] On Tuesday 18 November 2003 23.59, you wrote: Hi - What $prefix did you install SDL into? This, I think, is the beginning of the errors you're seeing. /usr/local That's fine, but aclocal/auto* are looking in the system's /usr/share/aclocal for the sdl.m4 file and that is why aclocal/automake is complaining that it can't find it. Couple things that can be tried are: put a symlink in the system's aclocal directory for sdl.m4 and point it at the one in /usr/local, the other thing is to copy the file into the system's aclocal directory. That may not be the only problem though and it may be necessary to install newer versions of automake and autoconf. Hi, 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 allocation error. Below I include the output. The y4mscaler part of the pipe can be omitted in order to reproduce the problem. I included it because it contains all informations about the video stream: [EMAIL PROTECTED]:/usr/local/xcdroast/MJPEG lav2yuv final01.eli |yuvdenoise | y4mscaler -I active=692x564+8+4 -S option=cubicCR -O preset=svcd | yuvplay INFO: [yuvdenoise] INFO: [yuvdenoise] Y4M2 Motion-Compensating-YCrCb-Denoiser INFO: [yuvdenoise] INFO: [yuvdenoise] Version: MjpegTools 1.6.2 ++ WARN: [lav2yuv] unspecified sample-aspect-ratio --- taking a guess... **ERROR: [yuvdenoise] malloc failed INFO: [y4mscaler] Input Stream Header: INFO: [y4mscaler]frame size: 704x576 pixels (608256 bytes) INFO: [y4mscaler]frame rate: 25/1 fps (~25.00) INFO: [y4mscaler] interlace: top-field-first INFO: [y4mscaler] sample aspect ratio: 59:54 INFO: [y4mscaler] SVCD output format requested in PAL/SECAM norm. INFO: [y4mscaler] Source matte region defaulting to full source frame. INFO: [y4mscaler] Target interlacing defaulting to match source. INFO: [y4mscaler] Target active region defaulting to full target frame. INFO: [y4mscaler] Deriving ratios from active regions and SARs... INFO: [y4mscaler] ...using scaling ratios which pad target. INFO: [y4mscaler] ...using scaling ratios which are simple. ++ WARN: [y4mscaler] Target active region clipped by projection of source. ++ WARN: [y4mscaler] Target active region y1 (6) is not multiple of 4... ++ WARN: [y4mscaler]...shifted down by 2. ++ WARN: [y4mscaler] Target active region y2 (570) is not multiple of 4... ++ WARN: [y4mscaler]...shifted up by 2. INFO: [y4mscaler] === SOURCE parameters: = INFO: [y4mscaler] stream: INFO: [y4mscaler]704x576, SAR 59:54, top-field-first INFO: [y4mscaler]chroma subsampling: 420_JPEG INFO: [y4mscaler]chroma ss ratios: x 1:2 y 1:2 INFO: [y4mscaler] active region: INFO: [y4mscaler]690.33x559.00 at 9.00,7.00 INFO: [y4mscaler] matte region: INFO: [y4mscaler]704x576 at 0,0 (bg Y'CbCr: 16,128,128) INFO: [y4mscaler] === SCALING parameters: INFO: [y4mscaler] | Scaler: Matto's Generic Scaler INFO: [y4mscaler] === TARGET parameters: = INFO: [y4mscaler] stream: INFO: [y4mscaler]480x576, SAR 59:36, top-field-first INFO: [y4mscaler]chroma subsampling: 420_MPEG2 INFO: [y4mscaler]chroma ss ratios: x 1:2 y 1:2 INFO: [y4mscaler] active region: INFO: [y4mscaler]460x560 at 10,8 (bg Y'CbCr: 16,128,128) INFO: [y4mscaler] X ratio: 2/3 INFO: [y4mscaler] Y ratio: 1/1 INFO: [y4mscaler] Output Stream Header: INFO: [y4mscaler]frame size: 480x576 pixels (414720 bytes) INFO: [y4mscaler]frame rate: 25/1 fps (~25.00) INFO: [y4mscaler] interlace: top-field-first INFO: [y4mscaler] sample aspect ratio: 59:36 INFO: [y4mscaler] Frame number 0 INFO: [y4mscaler] End of stream at frame 0. INFO: [yuvplay] Played frames (0:00:00.00) [EMAIL PROTECTED]:/usr/local/xcdroast/MJPEG Some days before, ther was a discussion of an similar bug (?) in mpeg2enc. How has it been resolved? Yours, Michael --- -- +---+ | Michael HankeRoyal Institute of Technology | | NADA| | S-10044 Stockholm | | Sweden | +---+ | Visiting
Re: [Mjpeg-users] MPEG2 encoding performance
On Thursday 13 November 2003 08.23, Steven M. Schultz wrote: On Thu, 13 Nov 2003, Michael Hanke wrote: On Tuesday 11 November 2003 23.30, Steven M. Schultz wrote: cvs update is your friend grin Mmmh... That's what I tried to do. But autoconf/automake (invoked by autogen) failed with many undefined macros/errors etc. So I gave up. If you've recent versions of the tools then it should work fine - works here on OS/X, Suse 9.0, BSD/OS and FreeBSD. automake 1.7.3 and autoconf 2.57 work well. libtool 1.4.x is what i use on most systems but OS/X came with libtool 1.5 and that had no problems (with mjpegtools, the mpeg4ip project has issues with libtool-1.5). Try it again but instead of giving up post the results and we'll see what we can do to help. You'll need the various development packages installed (glib, X, perhaps SDL) of course. Once the requirements are satisfied then ./autogen.sh should work. This is very kind of you. The system is a SuSE 7.2 with security updates from SuSE and with KDE3.1. Moreover, SDL 1.2.5 is installed by hand. These are the versions of the autoconf system: libtool 1.3.5, autoconf 2.53, automake 1.6.1, m4 1.4o. I do not like to update these tools because it's a running system... By the way, I got similar results on a SuSE 8.1 box. And here are the results of autogen.sh: **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. processing . Running libtoolize... You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. Running aclocal -I ./movtar ... aclocal: configure.in: 414: macro `AM_PATH_SDL' not found in library Running autoheader... autoheader: `config.h.in' is created Running automake --gnu ... configure.in:9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER' configure.in:12: no proper implementation of AM_INIT_AUTOMAKE was found, configure.in:12: probably because aclocal.m4 is missing... configure.in:12: You should run aclocal to create this file, then configure.in:12: run automake again. configure.in: installing `./install-sh' configure.in: installing `./mkinstalldirs' configure.in: installing `./missing' aenc/Makefile.am: installing `./depcomp' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in AM_CONDITIONAL lavtools/Makefile.am: installing `./compile' /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL [snip] Tons of the same message automake: processing Makefiles another time to fix them up. Running autoconf ... configure.in:12: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.in:13: error: possibly undefined macro: AM_MAINTAINER_MODE configure.in:14: error: possibly undefined macro: AM_OUTPUT_DEPENDENCY_COMMANDS configure.in:51: error: possibly undefined macro: AC_GNU_SOURCE configure.in:65: error: possibly undefined macro: AM_PROG_AS configure.in:68: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:200: error: possibly undefined macro: AM_PATH_GLIB configure.in:360: error: possibly undefined macro: AM_CONDITIONAL Running ./configure --enable-maintainer-mode --enable-compile-warnings ... checking build system type... i686-suse-linux checking host system type... i686-suse-linux checking target system type... i686-suse-linux ./configure: line 1340: syntax error near unexpected token `AM_INIT_AUTOMAKE(mjpegtools,' ./configure: line 1340: `AM_INIT_AUTOMAKE(mjpegtools, $MJPEG_VERSION)' Michael --- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Mon, 2003-11-03 at 09:14, Steven M. Schultz wrote: If you do that (and it has almost always improved the compression for me - sometimes quite substantially) then you may encounter playback difficulties with Ogle - seems they don't handle the dual prime motion estimation :( Other players (including settop boxes) have no problem though. So, essentially you're saying that MPEG2 without B-frames is perfectly legal from the DVD standards p.o.v., right? I'm asking this because standalone players are quite anal w.r.t. the standards. -- Florin Andrei http://florin.myip.org/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Mon, 2003-11-03 at 06:14, Andrew Stevens wrote: -f 8 -E -10 -q 6 -R 0 -I 0 -K tmpgenc Hmmm... I'm using 1.6.1.90 and i cannot find some options (-E, -10, -R) in the man page nor in the --help output. Are you using a recent CVS or something? -- Florin Andrei http://florin.myip.org/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On 11 Nov 2003, Florin Andrei wrote: On Mon, 2003-11-03 at 06:14, Andrew Stevens wrote: -f 8 -E -10 -q 6 -R 0 -I 0 -K tmpgenc Hmmm... I'm using 1.6.1.90 and i cannot find some options (-E, -10, -R) in the man page nor in the --help output. Are you using a recent CVS or something? You'd expect one of the primary developers to be running anything except the latest CVS version? grin The cvs version's the only thing I've run for years - it's rarely unstable or unbuildable and if that does happen it is fixed very quickly. Main feature that 1.6.1.90 brought to the party was the -K option and libquicktime (instead of the old/incompatible quicktime4linux) support. Since then quite a few improvements have been made. Cheers, Steven Schultz --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
Hi! On Tuesday 11 November 2003 17:10, Steven M. Schultz wrote: Main feature that 1.6.1.90 brought to the party was the -K option and libquicktime (instead of the old/incompatible quicktime4linux) support. Since then quite a few improvements have been made. Yes, lots of new features... Can we expect a stable _release_ version anytime soon? Current CVS mjpegtools are FAR better than 1.6.1 but it is impossible to get it in the packaged form - all distributions are packaging the latest release... :-((( Alexei --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Tue, 11 Nov 2003, Alexei Dets wrote: Yes, lots of new features... And a couple bugs ;) Can we expect a stable _release_ version anytime soon? Current CVS mjpegtools Not at the moment, there are a couple issues (boundary cases that most folks would not notice) that are being worked on. A 'release candidate' or 'snapshot' perhaps would be a good thing. are FAR better than 1.6.1 but it is impossible to get it in the packaged form For me a .tar.gz or 'cvs update' is packaging enough :) - all distributions are packaging the latest release... :-((( And they will always be months behind the 'cvs' version of mjpegtools or other projects. There's no getting around the fact that folks who want the current feature set of a project need to obtain and build the cvs version (most folks only have to worry about Linux - I have 3 or 4 different OSs that run mjpegtools and it's not that difficult). That is even more true with projects (such as ffmpeg or MPlayer) that change frequently (sometimes hourly ;)). Mjpegtools doesn't change quite as often (thankfully ;)) but will still be out of sync with many/all of the various distributions' release cycles. cvs update is your friend grin Steven Schultz --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
Hi, On Tue, 2003-11-11 at 22:53, Alexei Dets wrote: Can we expect a stable _release_ version anytime soon? Current CVS mjpegtools are FAR better than 1.6.1 but it is impossible to get it in the packaged form - all distributions are packaging the latest release... :-((( Wink noted again. I was intending to do that shortly after releasing 1.6.1.90, but then both Andrew and Stefan made some large changes to CVS, so I'm currently holding off until I'm sure that we're back to fully stable again. Stable doesn't only mean that it doesn't crash, but it means, too, that we've reached a state where the applications are known to produce results that meet all our standards. And we've set these pretty high in the past few years, I think. If people think that yuvdenoise and mpeg2enc are more than ready for a stable release, I'll package a 1.6.1.91... Else, I'll wait a few days longer. ;). Ronald -- Ronald Bultje [EMAIL PROTECTED] Linux Video/Multimedia developer --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Tue, 11 Nov 2003, Ronald Bultje wrote: If people think that yuvdenoise and mpeg2enc are more than ready for a stable release, I'll package a 1.6.1.91... Else, I'll wait a few days longer. ;). yuvdenoise was a problem this past weekend on OS/X - but it is working now after I tracked down the problem and checked a fix in. mpeg2enc has a couple of buglets that Andrew is looking into (I frame only encoding is not working at the present time for example). It's good for a snapshot to get wider testing but perhaps it would be a good idea to wait until this weekend or early next week. Cheers, Steven Schultz --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Tue, 2003-11-11 at 13:53, Alexei Dets wrote: Can we expect a stable _release_ version anytime soon? Or at least a 1.6.1.91 type of thing... ;-) When CVS seems healthy enough for a partial release. -- Florin Andrei http://florin.myip.org/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Tue, 2003-11-11 at 13:07, Steven M. Schultz wrote: On 11 Nov 2003, Florin Andrei wrote: So, essentially you're saying that MPEG2 without B-frames is perfectly legal from the DVD standards p.o.v., right? They are, and always have been, optional. Nothing says that B frames _must_ be used. In many cases they are a win but with less than perfect source material there are times when they lose and you're better off with more P frames. What is _your_ source? Mine is a recent el-cheapo Sony digital camcorder (DCR TRV240); kinda good in full daylight, but rather noisy in indoors scenes. Is that less than perfect enough to warrant dropping the B-frames? (i know, i have to try before knowing for sure, but i'm curious what your estimate is) -- Florin Andrei http://florin.myip.org/ --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
If people think that yuvdenoise and mpeg2enc are more than ready for a stable release, I'll package a 1.6.1.91... Else, I'll wait a few days longer. ;). Ronald There was a problem reported a while back with post-1.6.1 yuvdenoise (that is, after my 4:1:1 patches) producing some visual artifacts. I looked into it enough to verify the problem exists for the provided input (but none of my own, that I can see), but I have not had a chance to try to track the problem down, and I don't recall seeing that anyone else had either. I'm not likely to get to it soon either, I'm afraid. But don't let that stop you... :) Dan --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
On Mon, 3 Nov 2003, Andrew Stevens wrote: Well... its got a little way to go before its professional quality... It's getting closer every week/month though ;) So, to compare like with like you have to compare default mpeg2enc and MPEG-4 encoder encoding full CCITT 720xY pictures with interlaced motion modes active and a BBP picture structure *and* identical pre-encoder processing. Indeed! When I see folks boast about 'real time' encoding (usually with ffmpeg's MPEG4/DivX) they're using SIF (352x240/352x288) and not full 720xY sized data - they're also not using B frames which as Andrew mentions are very cpu intensive. The only time I've seen encoding rates at or below 3fps is on my older Pentium3 systems. - Go to P frames only (this may sometimes even improve compression!). If you do that (and it has almost always improved the compression for me - sometimes quite substantially) then you may encounter playback difficulties with Ogle - seems they don't handle the dual prime motion estimation :( Other players (including settop boxes) have no problem though. With noisier material the savings from turning off B frames are often on the order of 10 or 15% on filesize. For example, on my 1700Mhz Athlon/XP, 243 Frames of NTSC (720x480) Movie Note: this is just the encoder. It is common for the MJPEG decoding and denoising/scaling etc etc to use pretty much the same CPU resources. I've noticed that yuvdenoise tends to be limited to 5 or 6 frames/sec so adding that to the mix introduces a bottleneck - at least for me. -f 8 -E -10 -q 6 -K tmpgenc user0m34.014s = 7.1 Frame/sec -f 8 -E -10 -q 6 -R 0 -I 0 -K tmpgenc user0m14.580s = 16.6 Frame/sec Ah, quite similar settings to what I've settled on ;) I've too have found that -q 6 -E -10 -K tmpgenc produces very good quality output. Hmmm, without the -I 0 I only get about 15 Frame/sec on my Athlon 2800. Does -I 0 make that big of a difference? Cheers, Steven Schultz --- 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
Re: [Mjpeg-users] MPEG2 encoding performance
Hi Steven, aside Lying around useless with the 'flu today but I have spent the time learning more about PIC code and shared libs Basically, I think if all the relevant libs are compiled for shared library usage we should be in business. I've modified the nasm sources so all the assmbler routines are PIC. The trick will be to hack a a little shell wrapper for 'nasm' so that it looks more like gcc to the libtool ;-) I also had a glance at the SIMD / vector intrinsics supported by gcc-3.x. Definately a cut above the old hand-hacked inline assembler stuff (as a quick look at James' AltiVec code will confirm). Once I; /aside Hmmm, without the -I 0 I only get about 15 Frame/sec on my Athlon 2800. Does -I 0 make that big of a difference? -I 0 really does make that big a difference. If you know you don't have interlaced material then you should always use it. One of the many many things for the list is a quick and dirty interlace-detector that activates this if the frame looks to have significant decorrelation between adjacent lines. Andrew PS Ronald: I don't think a gstreamer wrapper for libmpeg2encpp will be too hard. However, I worry about the fact that I need to link all the C++ library routines. Are there any existing C++ based plugin's? --- 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
