AnsweredAssumed Answered

JPEG encoding speed on a BF561

Question asked by SpacedCowboy on Sep 10, 2012
Latest reply on Sep 27, 2012 by SpacedCowboy

I'm trying to decide the best way to solve the below problem, and a fast DSP is one of the ways I'm looking at using. Here's what I'm trying to do:


Consider a "bunch" (read: not sure how many, but say at least 10) of SD video feeds, each frame from each video source being encoded into a JPEG image and sent over a 100BaseT network to a server where it can be stored. I obviously need realtime JPEG compression at the video source to do this, as well as have enough cycles left over to stuff packets down the wire.


Doing some research on DSP's (I've never used them), it seems Analog are claiming that they can encode an SD video frame on a Blackfin DSP in about 12 million cycles at a reasonable compression factor - so with a 600MHz DSP, it seems there's room and enough for 30fps. My issue is that elsewhere on the net, I see people saying they're only getting a frame out in ~96ms, which is way slower than I need. Confusion ensues :(


So, if I were to buy the Blackfin EZ-KIT with the BF561 on board, is it a reasonable supposition to say I could be creating JPEG compressed data without dropping any ? I can handle the ethernet by using an ENC28J80 and sending the data over SPI from the DSP, so it's really down to just how fast the DSP really is. Given that the 561 is a dual-core DSP, it may be possible for me to split the encoding load, although for other reasons I'd prefer it to be possible with leaving me that second core for other things.


I've looked at doing this with FPGA's (with which I do have some experience), with a grid of XMOS chips, and with a honking ARM chip. The DSP looks like it needs the least amount of "support" around it, so it'd get the vote if it can do it. Which is the big question...


So, can it ?


Any help appreciated :)