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
Re: Malloc failed, Was: Re: [Mjpeg-users] MPEG2 encoding performance
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
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 --- -- +---
Re: [Mjpeg-users] MPEG2 encoding performance
On Mon, 17 Nov 2003, Michael Hanke wrote: > > 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 > This is very kind of you. The system is a SuSE 7.2 with security updates from You're welcome. Hmmm, 7.2 is a bit old but should work. > SuSE and with KDE3.1. Moreover, SDL 1.2.5 is installed by hand. These are the What $prefix did you install SDL into? This, I think, is the beginning of the errors you're seeing. > 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... Quite understandable. The versions of automake and m4 should be fine, autoconf and libtool are a bit old but shouldn't cause a problem It is possible to have more than one version of automake installed on the system at one time. There is of course the risk that the wrong one will be used if you forget to use 'alias' or a different method to select the correct one. > By the way, I got similar results on a SuSE 8.1 box. Oldest system I had was SuSE 8.2 but it was upgraded to 9.0 a week or so ago. > And here are the results of autogen.sh: > > 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 That is the beginning of the end. 'aclocal' did not run successfully and that means automake will not run successfully and that in turn means ./configure will not run properly. I believe the problem is that the sdl.m4 file did not get installed where 'aclocal/automake' could find it. Two ways to work around this problem: 1) cp sdl.m4 /usr/share/aclocal/sdl.m4 or 2) create a symlink in /usr/share/aclocal/ to point to the sdl.m4 file. > Running autoheader... > autoheader: `config.h.in' is created > Running automake --gnu ... > configure.in:9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER' Hmmm, that error does not appear if I use automake 1.7.3. If that continues to cause a problem you can edit configure.in and change AC_CONFIG_HEADER to be AM_CONFIG_HEADER. It is beginning to look like a dependency on a newer version of automake has been introduced into mjpegtools ;( automake 1.5 is supposed to be sufficient but that might not be correct now. > configure.in:12: no proper implementation of AM_INIT_AUTOMAKE was found, > configure.in:12: probably because aclocal.m4 is missing... That's expected - aclocal did not run to completion and without aclocal.m4 automake will not run correctly. AM_INIT_AUTOMAKE is crucial and if automake doesn't detect it. The rest of the errors occur because of the earlier errors from aclocal and automake. If you can't get the existing version of automake/aclocal to work then it will be necessary to install a newer version. Good Luck. Steven Schultz --- 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 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 > > > > 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
Did I just hear elimination of B frames: 1) lowers bitrate, ie file size 2) improves output 3) faster encoding (ok so i'm reaching) so, basically, unless you're editing, B frames are a 3 strike out, IMO. - Original Message - From: "Steven M. Schultz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 11, 2003 6:55 PM Subject: Re: [Mjpeg-users] MPEG2 encoding performance > > On 11 Nov 2003, Florin Andrei wrote: > > > What is _your_ source? > > Which one? ;) > > The author of mpeg2enc is one. Another can be found in one of > the links from http://www.mir.com/DMG/, go to the MPEG FAQ > and read http://tns-www.lcs.mit.edu/manuals/mpeg2/FAQ > > Question/answers #16, #19, #20 and #24.5 > > In particular #16 which gives the definitions of the MPEG profiles, > note that the "Simple" profile is I and P frame only.One could > look up the formal definitions in one of Charles Poynton's books > but for now the FAQ will suffice ;) > > The discussion in #19 and #20 is quite interesting - in essence > at higher (relative to MPEG-1 SIF size) bitrates B frames are > considered by some to be 'wasted bits'. > > Then in #24.5 there's the Dual Prime prediction discussed. That's > the part that Ogle doesn't implement but it is most certainly > a part of the standard. > > > 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? > > Same here - actually mine's the TRV140 (or was it the 120) - D8 so it's > not analog but nothing fancy (that's for sure :)). Thinking of > getting one of those 3CCD units (Panasonic has one that can be had > for under $1k) one of these days. > > Anyhow I shot some footage of the fires that were going on in > Southern California a short time ago (just a couple miles from > the house) and got somewhere around 10% or so reduction in the > bitrate by dropping B frames.I've some tapes made earlier > that I could re-capture and experiment with. > > It's also possible to split the difference - instead of dropping > B frames completely you can specify that just 1 is to be used between > P frames. The "-R 1" will reduce but not eliminate the B frames. > > It's been mentioned to me that high motion scenes can also benefit > from reducing or eliminating the B frames. Something to consider > when going for maximum quality with live footage. > > 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 > --- 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 Thu, 13 Nov 2003, Michael Hanke wrote: > On Tuesday 11 November 2003 23.30, Steven M. Schultz wrote: > > > > "cvs update" is your friend > > > 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. 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 Tuesday 11 November 2003 23.30, Steven M. Schultz wrote: > > "cvs update" is your friend > 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. Michael --- 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 Wed, 12 Nov 2003, John Ribera wrote:
> Did I just hear elimination of B frames:
Not exactly ;)
They are optional now though so you can choose if you want/need
them or not.
> 1) lowers bitrate, ie file size
In some cases - mostly with noisy sources. Good clean (D8, DV)
input will not benefit as much (might even grow a few percent).
> 2) improves output
It's supposed to improve output in the high motion scenes, true.
> 3) faster encoding (ok so i'm reaching)
Not at all. B frames are much more cpu intensive than I or P
frames to compute - not generating B frames brings a fairly
substantial boost in encoding speed.
> so, basically, unless you're editing, B frames are a 3 strike out, IMO.
Two strikes - the B frames have a place and perhaps just using 1
of them ("-R 1") would be a Good Thing in some cases.
There's no hard rules for "always use feature XXX" or "never use
feature ". Encoding is very sensitive to the source of the
data as well as the other parameters being used - it could well
be that using the high resolution quantizing matrices with the
"-E -10" option will work better using 1 B frame than leaving out
the B frames completely.
Encoding the data multiple times to try out various combinations is
a time consuming but necessary job in some cases. Obviously for
casual viewing (and discarding of the movie after viewing) it's not
important to select the "best" parameters. When making DVDs for
archival or viewing by a wider audience then it can be worth the
time to do several trial encodings and select the best looking one.
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 11 Nov 2003, Florin Andrei wrote: > What is _your_ source? Which one? ;) The author of mpeg2enc is one. Another can be found in one of the links from http://www.mir.com/DMG/, go to the MPEG FAQ and read http://tns-www.lcs.mit.edu/manuals/mpeg2/FAQ Question/answers #16, #19, #20 and #24.5 In particular #16 which gives the definitions of the MPEG profiles, note that the "Simple" profile is I and P frame only.One could look up the formal definitions in one of Charles Poynton's books but for now the FAQ will suffice ;) The discussion in #19 and #20 is quite interesting - in essence at higher (relative to MPEG-1 SIF size) bitrates B frames are considered by some to be 'wasted bits'. Then in #24.5 there's the Dual Prime prediction discussed. That's the part that Ogle doesn't implement but it is most certainly a part of the standard. > 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? Same here - actually mine's the TRV140 (or was it the 120) - D8 so it's not analog but nothing fancy (that's for sure :)). Thinking of getting one of those 3CCD units (Panasonic has one that can be had for under $1k) one of these days. Anyhow I shot some footage of the fires that were going on in Southern California a short time ago (just a couple miles from the house) and got somewhere around 10% or so reduction in the bitrate by dropping B frames.I've some tapes made earlier that I could re-capture and experiment with. It's also possible to split the difference - instead of dropping B frames completely you can specify that just 1 is to be used between P frames. The "-R 1" will reduce but not eliminate the B frames. It's been mentioned to me that high motion scenes can also benefit from reducing or eliminating the B frames. Something to consider when going for maximum quality with live footage. 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
> 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 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
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, 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
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, 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 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 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. 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 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? 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
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 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
Hi Andrew, On Mon, 2003-11-03 at 18:49, Andrew Stevens wrote: > 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? Lots. Modplug, matroska. Probably some more that I forgot about. Afaik, you don't need anything specific, libtool-1.5 handles it all. You could start with the old gstmpeg2enc.c wrapper as a start: http://cvs.sf.net/viewcvs.py/gstreamer/gst-plugins/gst/mpeg2enc/Attic/. You'll notice in the CVS commit comments that it was removed because we removed all non-LGPL code from our CVS tree some time ago. However, linking to non-LGPL libs is still ok... Ronald -- Ronald Bultje <[EMAIL PROTECTED]> Linux Video/Multimedia developer --- 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
On Mon, 3 Nov 2003, Andrew Stevens wrote: > > 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. What is it about interlacing that makes it so hard? I can see how trying to detect interlaced vs progressive source, or an inverse-telecin filter, would be extra work. But is a 720x480x30fps interlace source really any different than a 720x240x60fps progressive source? --- 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, 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; > > 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
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 720x 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 720x 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 Laurent, > I might be wrong as I don't have an in-depth knowledge of MPEG2 and MPEG4 > compression, but it seems to me that MPEG4 compression is more time > consumming than MPEG2. > > I know that mpeg2enc is a professional-quality tool that can give extremely > good quality MPEG2 streams. Well... its got a little way to go before its professional quality... > However, I'd like to know if anyone has ever > profiled mpeg2enc to find where the performance bottleneck is. I don't > expect mpeg2enc to give me real-time encoding performances (quality comes > at a cost), but 3fps seems very low compared to 25fps. Errr... not just 'ever'. I *regularly* profile mpeg2enc. The main bottleneck is motion estimation especially if B frames are being used. Here's why there's such a big difference: 1. Size of frame. Processing resources rise with nearly the cube of frame size when you compare like with like. Why? Easy, you increase the number of pixels by the square of frame dimensions. However, to keep your motion estimation radius the same (in terms of fractions of a frame) that has to increase too so the area you search for each macroblock increases by the square of dimensions too. 2. B Frames. B Frames are nasty because you have to motion estimate not over a single frame interval but 1 frame in one direction and 2 frame intervals in another. If you want to cover motion of a given speed you have to search 5 (1+2*2) times as many pixel positions as if you were doing simple back-to-back P frames. The P frames that come every 3rd frame need to cover 9 times as many pixels compared with back-to-back P frames. 3. Interlaced motion modes. If you leave the interlaced motion estimation on mpeg2enc motion estimates on a frame *and* a field basis. This nearly doubles the amount of work it has to do. 4. Type of motion estimation. mpeg2enc uses a relatively expensive hierarchical exhaustive motion estimation search. This means you have a high probability of finding a rather good or even optimal motion vector. You can do 'nearly' as well using predictor/corrector motion estimation algorithms which are many times faster. 5. The use of variance based encoding mode selection. Sum of absolute differences is would be much faster and nearly as good. 6. A sub-optimal encoding data-flow inherited from the original MSSG reference encoder. A couple of bits in mpeg2enc are just not terribly well thought out for speed. So, to compare like with like you have to compare default mpeg2enc and MPEG-4 encoder encoding full CCITT 720x pictures with interlaced motion modes active and a BBP picture structure *and* identical pre-encoder processing. If you want to encode MPEG2 SVCD/DVD fast with mpeg2enc. You should: - Turn off interlaced mode if it is not needed. Basically, any movie material! - Go to P frames only (this may sometimes even improve compression!). 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. INFO: [lt-mpeg2enc] Frame end 224 B quant=8.52 total act=17159.02351 -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 Now if we go to smaller frames SVCD (480x480) -f 4 -E -10 -q 6 -K tmpgenc user0m23.770s = 10.3 Frame/Sec -f 4 -E -10 -q 6 -R 0 -I 0 -K tmpgenc user0m9.900s= 24.5 Frame/sec Now if we go to smaller frames still VCD (352x240) -f 1 -E -10 -q 6 -K tmpgenc user0m4.50s = 54 Frame/Sec -f 1 -E -10 -q 6 -R 0 -K tmpgenc user0m4.140s= 58 Frame/Sec As you can see. The encoder just about reaches real-time performance on MPEG-4 typical stream resolutions and format. If a predictor/corrector motion estimator were added it would it would easily hit real-time performance on modest hardware. Andrew --- 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
[Mjpeg-users] MPEG2 encoding performance
Hi everybody, This is not the first mail about MPEG2 encoding performance, and probably not the last one either. I'm comparing here the encoding performances of ffmpeg (MPEG4) and mpeg2enc. On a PIII-800, the former encodes in real time while the later encodes at around 3fps. I might be wrong as I don't have an in-depth knowledge of MPEG2 and MPEG4 compression, but it seems to me that MPEG4 compression is more time consumming than MPEG2. I know that mpeg2enc is a professional-quality tool that can give extremely good quality MPEG2 streams. However, I'd like to know if anyone has ever profiled mpeg2enc to find where the performance bottleneck is. I don't expect mpeg2enc to give me real-time encoding performances (quality comes at a cost), but 3fps seems very low compared to 25fps. Laurent Pinchart --- 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
