Hi "b.", First off we need to make sure we're comparing like with like. For a test.avi which is 720x568 full-size PAL video:
lav2yuv test.avi | mpeg2enc -f 8 -o /dev/null my old PIII-500 (Katmai core) delivers just under 1.5 frames/sec. my Duron-800 delivers roughly 3 frames/sec. my Athlon/XP 2100+ (a 1800Mhz device) gets 6 frames/sec. This is running with the encoder defaults which are set more for get-the-last-drop-on-faster-CPUs than for a good trade-off on older devices. If I switch to less exhaustive motion estimation and turn off support for interlaced motion compensation lav2yuv test.avi | mpeg2enc -f 8 -4 4 -2 4 -I 0 -o /dev/null the PIII-500 delivers around 3 frames/sec. > 800MHz Athlon ThunderBird. > lav2yuv test.avi | /usr/src/mjpeg_play/mpeg2enc/mpeg2enc -f 3 -4 4 -2 4 -q12 -b 4500 -V 300 -I 1 -o test.m2v So, 2 frames/sec is really slow for this CPU with NTSC (720x480) frames on this CPU. Now you're getting: INFO: [mpeg2enc] SETTING 3DNOW and EXTENDED MMX for QUANTIZER! INFO: [mpeg2enc] SETTING EXTENDED MMX for MOTION! INFO: [mpeg2enc] SETTING MMX for TRANSFORM! INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION! on start-up. So the main MMX/3D-Now! routines are being enabled. My first point of suspicion would be your build of lav2yuv. If that is using the normal jpeglib and not the hacked jpeg-mmx it is going become a serious bottleneck in the encoding process. The other issue may be memory. By default mpeg2enc is very greedy with RAM buffering lots of frames to allow good performance on multiprocessor machines or where decoding/filtering is running on a seperate machine across the network. >The material is (going to usually be) interlaced as this is television >broadcast. Not necessarily. If the original material was Movie and you you do a reverse telecine (reverse 3:2 pulldown) using yuvkineko you'll get progressive material. A lot of major TV series are shot on Movie stock rather than NTSC video as it produces *much* better quality results when converted to PAL for export. If you can encode progressive the results are always much superior - basically you're encoding 24 frames/sec instead of 30. >I am using those along with -q 31 and still getting only about 2 fps. -q has absolutely no effect whatsoever on encoding speed. It simply tells the encoder what quality of encoding to aim for. I.e. for bits of video where the available bitrate is high enough this will be the base quantisation (precision) of the encoded video. See HOWTO / man pages. The only flags that affect speed are -4 -2 -r and -I. -4 and -2 set to max speed (-4 4 -2 4) will slightly increase the size / reduce the quality of the video. However, the reduction in quality is *below the visual threshold* it is only noticeable in statistics. Setting -r to 8 or less will produce some speed gains at the cost of increased bit-rate demand in high-motion scenes. This will have little impact on overall file size if you set the peak bitrate high enough but will be bad news for quality on badly rate-limited formats like SVCD. The -I flag tells the encoder whether it should bother trying motion compensations that handle interlacing. If you have progressive material (i.e. you have deinterlaced or the original is movie material) the default for MPEG-2 (-I 1) is a complete waste of CPU resources and -I 0 will produce as good if not better results. However, if material is interlaced you'll definately want -I 1 unless your encoding at a really high bit rate for and just don't care about file size. > Nope. Got MMX. What CPU are you using and what speeds do you get? > > > I believe ffmpeg had a fairly quick MPEG-1 encoder. > > And zapping's mp1e is even faster, but I do want mpeg2 if I can get > it. > > > -4 4 -2 4 > > I am using those along with -q 31 and still getting only about 2 fps. > > > The cost in quality is probably not noticeable over default. > > This is broadcast (over analog cable) material anyway that I only > intend to watch once and delete. Then -4 4 -2 4 and -r 8 or -r 0 are your friends. Crank the bitrate ceiling to 10Mbps , set -q around 5 and enjoy... don't forget to capture at a decent quality setting (-q 50 or so). I am starting work on mpeg2enc seriously again now. There should be some speed improvements for "high speed quick and dirty encoding" as an early side-effect of some internal changes. Some things that aren't really a big deal when the motion estimator is working really hard become a bottleneck when it is turned right down. Another important "quick and dirty" improvement I want to add in will be support for letterboxed video (currently the encoder will waste a lot of effort on the black margins ;-)). Andrew ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users