On Tue, 2003-12-16 at 10:27, Steven M. Schultz wrote: > On Tue, 16 Dec 2003, Slepp Lukwai wrote: > > > Tried it without any options, same effect. I'm definitely seeing nowhere > > near 40% speedup, which is what boggles me. I expected at least > > reasonable gains of 25%. > > I think that has to do with the -I setting...
The -I is frightening me. Take a look at my previous post with the -M x -I x -R x settings on each. The -I 1 with two B frames (-R 2) shows a huge gain over the -M 0 -I 1 -R 2, but it is still significantly slower than -M 3 -I 0 -R 1 or 2. > > Sorry, upon further testing, I actually average around 14fps at DVD > > quality (720x480, 9800kbit/s). (see all the details of my command lines > > Ah, that's more like it then. Yup. > > It's interesting that I'm faster with dual 2100s than the dual 2800 (or > > at least on par). I suppose it really comes down to command line > > options, but you would need to compare those yourself (since I haven't > > Friend of mine has dual 2400s and my setup is ~10-15% faster as I > recall - he's getting around 11fps as a rule where I see 14 or so. > > I'm usually adding a bit of overhead with the chroma conversion. I > build smilutils with ffmpeg/libavcodec (to use ffmpeg's DV codec) > and then run the data thru something like: > "smil2yuv -i 2 file.dv | filters | y4mscaler -O chromass=420_MPEG2 |..." > > Produces better output that the default which uses libdv but does > cost a bit in cpu use. You could run my test case. I pre-decoded an MPEG2 DVD stream into 1010 frames and then used this: for M in 0 1 2 3 ; do for I in 0 1 ; do for R in 0 1 2 ; do export LD_LIBRARY_PATH=/home/slepp/mp/lib ; echo -M $M -I $I -R $R ; time /home/slepp/mp/bin/mpeg2enc -f 8 -M $M -g 9 -G 18 -I $I -v 0 -E -10 -K kvcd -4 2 -2 1 -R $R -F 1 -o test-$M$I$R.m2v < pgmy4m.raw ; done ; done ; done It was rather handy, but it took a long time to run. The source pgmy4m.raw is 536MB here. > > According to the docs -I 1 turns on interlacing support, and causes > > un-needed overhead if it is known progressive material. Hence the -I 0 > > (plus transcode sets that, though I could override it). > > But unless you have the raw 23.976fps progressive data (with the 3:2 > pulldown undone) then I think '-I 1' is the option to use. But then > I might be confused (wouldn't be the first time ;)). Yup. It's MPEG-2 DVD @ 23.976 fps, and I need to add in the pulldown. > That would explain why the encoding rate I see is lower since I'm > using -I 1. See above. :> > > > wrong I'm sure someone will tactfully point that out ;)) the speedup > > > comes from the motion estimation of the 2 fields/frame being done in > > > parallel. > > > > Oh. Son of a... If that's all it is... > > Yep - I'm fairly sure that is why you're not seeing any improvement > when using "-M 2". You're right that -I improves performance over baselines later on, but it doesn't improve over -I 0. > On noisy source material the -E option has almost no effect but the > cleaner the input the more effect even modest values of -E have. So a -E helps with transcoding these DVDs. > > now, in combination with -Q, but I find the artifacts are almost never > > there (I used to do -q 4 and -Q 4.0, and it looked about the same as the > > 5/3.0). > > Perhaps Richard Ellis could chime in with his experiences with -Q ;) I will need to look at that. :> Any idea how it impacts performance? > Looking back on it that makes sense though. A P frame depends on the > preceeding P frame - rather sequential in nature since you can't > move on to the next one without completing the first one... But it would make sense, I thought, to do IPBBPBBPBB on thread 1 and IPBBPBBPBB on thread 2. So each thread does a GOP (in fact, I found a marginal increase ins peeds by using a gop size of 3 (-g 3 -G 3) and -M 3, it was a little faster than when I had variable gop sizing). But, I think that the encoder doesn't stream it that way, but rather does the I frame, then fires off the P frame, then each B is done in parallel, and then it does another P, etc. > > The MPEG decoding doesn't take much, and the pipe overhead is negligble, > > Pipe overhead sneaks up on you though. One pipe? Not a real problem, > two? Begins to be noticed but isn't too bad. Four or five? Yeah, > it starts to take a hit on the overall speed of the system - the data > has to go up/down thru the kernel all those times and that's not "free". Everything should be free. ;> What I'd like to test, just for fun, is to fire up mpeg2enc on one of the 16 processor SGI systems at the University and see how that threads across 16. It says it doesn't do well above 4, but again, it's fun to try. > You might try, for timing purposes, without -I 0 and see what, if any > effect that has. Might be a useful data point. Once again, take a peek at my last e-mail to the list. It has timings in it for a total of 24 tests. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
