We may need to compress in the order of 100 jpegs per second. Any ideas if there is good hardware for this?
Thanks.
Reza.
We may need to compress in the order of 100 jpegs per second. Any ideas if there is good hardware for this?
Thanks.
Reza.
Of which size? If the image sizes are not too large, it doesn't sound too unrelaistic that you can do that with off-the-shelve PC hardware.
So long, Thomas
Un bel giorno RezaRob digitò:
Try this:
-- emboliaschizoide.splinder.com
Or, if he wants low-cost embedded hardware, an ARM processor or a DSP chip with appropriate software should do the trick.
There probably is, seeing that MJPEG (Motion-JPEG, not to be confused with MPEG) is nothing but a stream of individual JPEGS. This is the format that, for instance, Mini-DV cameras use and probably pro gear as well.
I'd look into the specs of professional digital video cameras and then try to find out what hardware they use. Or maybe there even are high-end consumer camcorders that do 100fps, who knows.
robert
Say, in the 800x800 range. I don't think the PC hardware can easily handle it, unless we devote a couple boxes to it.
Reza.
That would be called a Mac.
-- #1 Offishul Ruiner of Usenet, March 2007 #1 Usenet Asshole, March 2007 #1 Bartlo Pset, March 13-24 2007 #10 Most hated Usenetizen of all time #8 AUK Hate Machine Cog Pierre Salinger Memorial Hook, Line & Sinker, June 2004 COOSN-266-06-25794
Zoran (NASDAQ:ZRAN) used to make a chipset that did this; it was used for many MJPEG boards such as the Iomega BUZ and Pinnacle DC30 and DC50 about 8 years ago. Unfortunately I can't find information on their corporate website about it, but it's possible they still sell and support it.
I don't think so.
thor@mersenne:~> time for ((i=0;i
Correct.
Wrong.
On a sunny day (Tue, 12 Jun 2007 18:28:55 +0200) it happened Thomas Richter wrote in :
I get very different results with a real 800x600 X windows grab import q1.ppm
-rw-r--r-- 1 root root 7928769 2007-06-12 20:14 q1.ppm import q1.pgm
-rw-r--r-- 1 root root 2675036 2007-06-12 20:16 q1.pgm ((i=0;i out.jpg; done about 40 seconds on 1GHz Duron.
Perhaps he could get some IP for FPGA. There must be chips for 30fps, most DV cameras must have one.
What do you expect from this machine? (-: Let's get realistic, please. Nothing against this machine, but a Duron is not a high-end CPU, and 1Ghz is not exactly up-to-date either.
So long, Thomas
We seem to be having a lot of problems getting somebody knowledgeable from them on the phone. I heard from two separate sources that they didn't really like to talk, except perhaps to large mass markets.
Reza.
On a sunny day (Tue, 12 Jun 2007 22:34:56 +0200) it happened Thomas Richter wrote in :
OK buy a PS3 a and code for the helper cores.
Still his example was wrong, I use a full high res 800x600 color, if it truely was only 3 mS for that, then it would be 100x3 = 300 ms. That would mean the Px whatever many cores was 120x faster then my Duron. No way, at the most 12 x (or 20x if dual core). So I'd like to see his results for a true 800x600 RGB grab with detail on that machine. Would surprize me it it was faster then 2 seconds for 100 conversions.
800 x 600 color image from a camera. real 0m6.734s user 0m5.556s sys 0m3.516s 2.4 GHz Core 2 Duo
DV cameras don't use motion JPEG. They both use a block-based DCT intra-coding scheme, but there are major differences.
Have you (op) looked at using an FPGA board as a coprocessor (or even standalone)? There are many inexpensive boards that could easily do what you need, but you'd need to write some VHDL or Verilog code.
There's a lot of code at opencores.org, but I haven't used any of it. If you consider FPGAs, comp.arch.fpga is a good source of advice.
...and we'll point you to IP sources like those at
On a sunny day (Tue, 12 Jun 2007 14:46:15 -0700) it happened "Pete Fraser" wrote in :
How long does this one take (the one I used?): ftp://panteltje.com/pub/q1.pgm I ran it again, but there is still an other H264 encode running I cannot interrupt now: for ((i=0;iout.jpg; done 27.19s user 1.53s system 96% cpu 29.758 total
Yours is only 4.1 x faster :-) Duron rules :-)
I'm not sure if I'm interpreting it incorrectly, but it seems to be a lot of ASCII numbers.
I just read the spec. That's a strange one. Should I do the timing reading the ASCII? I'm not even sure if cjpeg can read ASCII images.
Why is it a 16-bit image?
I should have tried it first.
real 0m42.325s user 0m40.105s sys 0m4.273s
I assume it spends most of the time dealing with a strange 16-bit ASCII input file.
Oh! Maybe they don't call it MJPEG, but isn't the compression scheme that DV uses some sort of JPEG, or is it a completely different form of compression?
Thanks for clarification, robert
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.