Dear All - Please forgive the broad audience. I am doing a security application and need to merge many of the features found in both ffmpeg and motion. Specifically, from motion I need to grab & process frames for motion activity, etc., then insert text strings into the frame such as time/date/location, then conditionally real-time encode them into a streaming format such as mpeg1 for archive and playback. Motion does a great job on the front end capturing video data from a v4l camera and performing motion detection and text insertion (though I did have to add char fonts to draw.c), but when its time to encode, it saves the individual frames as jpeg or ppm, then calls mpeg_encode. This essentually results in a capture-then-encode sequential pipeline vs. a encode-while-activity-(possibly-forever)-and-insert-text-data-while-doing-it nature that I need. I hacked mpeg_encode and motion to sync them in such a way that mpeg_encode waits and encodes then deletes sequential files from motion as they are being produced, but I can't seem to break 12 fps. I have optimized by using a ramdisk as the temp file location, and tuned the put_ppm() creation routine (these obvious things helped speed up from 8 fps). I really need 30 fps at 1500 kbps. Also, mpeg_encode can't encode (properly) at less than 24 fps. NOTE: 400 Mhz PII/Celeron, 128 MB. ( A note on mpeg_encode: while this code seemed to function very well, its performed poorly. Upon examining the code, there are MANY points in which can be optimized for speed.) I believe that the fundemental problem with this approach is the cpu time spent creating and converting intermediate image files (the switch from jpeg to ppm (a non-compressed format) helped alot, but only if going through a ram disk). It seems to make sense to replace mpeg_encode with ffmpeg. It's mpeg encoder seems faster. However, as I am getting more familiar with this video stuff, it seems like in order to do image manipulation and text insertion, the image has to be captured or converted to RGB. However, before converting to MPEG, it ultimately must be converted to YUV420P (???). Here again, it looks like in order to get the best performance, I must find the common denominators and eliminate expensive conversions. Can anyone advise as to a more practical or streamlined approach? Specifically, I need to capture from a v4l (i.e., bt878) device, perform some limited image process operations (i.e., motion detection), insert text strings (i.e, time/date/location), then encode to a streamable archive source with quality equilivelent to VHS. Best regards, Joe Briggs
