On Monday 31 December 2001 12:28 pm, joe briggs wrote: > 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-i >t 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
