Hi all,
First off a bit of background to the multi-threading in the current stable
branch. First off:
- Parallelism is primarily frame-by-frame. This means that the final phases
of the encoding lock on completion of the reference frame (prediction and DCT
transform) and the predecessor (bit allocation). If you have a really fast
CPU that motion estimates and DCT's very fast you will get lower
parallelisation. If you use -R 0 you will get very litte parallelism *at
all*. Certainly not enough to make -M 3 sensible.
- There is also a parallel read-ahead thread but this rarely soaks much CPU on
modern CPUs.
The MPEG_DEVEL branch encoder stripes all encoding phases to allow much more
scalable parallelisation. You might want to give it a go - I'd be interested
in the results!
N.b. in a 'realistic' scenario you're running the multiplexer and audio
encoding in parallel with the encoder and video filters communicating via
pipes and named FIFO's. This setup usually saturate a modern dual machine
cheers,
Andrew
PS
I'm away on vacation for a couple of weeks from friday so there'll be a bit of
pause in answering emails / posts from then ;-)
-------------------------------------------------------
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
