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
