Sorry for the two posts, didn’t notice your other reply! (Getting hungry nearly lunch time!) Well im thinking if I fork the master process and use parent to do the capturing continusoly and the child process to do the write, and using a pipe between the two to get the data between the two. All theory atm but im thinking it shuld work quite well. RE: JPEG compression - the libjpeg is screwed on my development box and I really cant be bothered fixing it!!!! So is there any alternatives than using this library, e.g. someone writen their own code? I really don’t have the time/energy or brain! To do my own. Well not until I go on another cafffeeeeene high. Thanks, Kind Regards, Matt Brocklehurst, LookCCTV. Tel: 01253 891222 Fax: 01253 891221 Web: www.lookcctv.com Email: matt@xxxxxxxxxxxx -----Original Message----- From: Roger Oberholtzer [mailto:roger@xxxxxx] Sent: 28 August 2003 12:51 To: video4linux-list@xxxxxxxxxx Subject: Re: Whats the best way of doing this! Which card are you using for this? I have just such a need. I do not need to keep the images, nor do I need a high rate. But, I would love to get four images from one card! With, it seems, 4 connectors. On Thu, 28 Aug 2003 09:29:54 +0100 "Matt Brocklehurst" <Matt.Brocklehurst@xxxxxxxxxxxx> wrote: > Hi, > Ive managed to finally get my V4l program to get a semi-good frame rate > (4fps) over 4 cameras on a single chipped bt878 card - displaying this > to screen no problem - however im at a loss how im going to dump the > camera images to disk! Anyway ive tried the fps drops off to something > icky (like 1fps). Any ideas/suggestions - source code would be nice! Not > too bothered about the format - as long as i can convert it at a later > date to jpeg no problems, just want the fastest way of dumping the > data. > > (Was thinking about threads - did attempt this but didnt seem to get > anywhere :( ) Threads are not necessarily faster. Depends on what you are up to. I do jpeg compression in one application and that helps alot. However, that is using a firewire digital camera providing YUV images. Still, the application stupidly converts these to RGB before passing it to the JPEG library, which I think converts them back (correction is on todo list). And the system keeps up while doing a ton of other things. We cheat and do not re-calculate the Huffman tables for each image. That also helps decrease conversion time. What type of hard disk are you using? We use good SCSI disks for these types of things. The performance improvement is noticeable. If you are using IDE disks, the CPU conversion to JPEG may actually offset the decreased data to be written. -- +····························+·······························+ · Roger Oberholtzer · E-mail: roger@xxxxxx · · OPQ Systems AB · WWW: http://www.opq.se/ · · Erik Dahlbergsgatan 41-43 · Phone: Int + 46 8 314223 · · 115 34 Stockholm · Mobile: Int + 46 733 621657 · · Sweden · Fax: Int + 46 8 302602 · +····························+·······························+ -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
