Forums

Video capture/compression

Started by Meindert Sprang March 30, 2007
Can anyone point me to manufacturers of video capture/compression chips? I'm
not looking for mainstream PCI bus solutions but something that can be
controlled by a microcontroller and a frame buffer.

A bit like what is on chip with the Omnivision CMOS camera chips and the
OV528 compressor. But I need to be able to connect standard analog CCIR
camera's

Meindert


On Fri, 30 Mar 2007 15:43:40 +0200, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:

>Can anyone point me to manufacturers of video capture/compression chips?
this along the lines of what you're talking about? http://focus.ti.com/docs/solution/folders/print/268.html also, maybe something helpful here: http://tinyurl.com/2q3rvb (this url goes google groups to a thread i started on this forum.)
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> skrev i meddelandet 
news:460d14ae$0$19044$e4fe514c@dreader31.news.xs4all.nl...
> Can anyone point me to manufacturers of video capture/compression chips? > I'm > not looking for mainstream PCI bus solutions but something that can be > controlled by a microcontroller and a frame buffer. > > A bit like what is on chip with the Omnivision CMOS camera chips and the > OV528 compressor. But I need to be able to connect standard analog CCIR > camera's >
Why not use a standard processor with camera interface?
> Meindert > >
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
news:eujspb$ni9$1@aioe.org...
> Why not use a standard processor with camera interface?
I don't know of any processors with a camera interface unless you mean types like the TI OMAP. This has to be a mass market cheap solution like the Omnivision stuff. It's just that we need to interface with 10's of thousands existing analog cameras... Meindert
On Saturday, in article
     <460e4f63$0$23099$e4fe514c@dreader12.news.xs4all.nl>
     ms@NOJUNKcustomORSPAMware.nl "Meindert Sprang" wrote:

>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message >news:eujspb$ni9$1@aioe.org... >> Why not use a standard processor with camera interface? > >I don't know of any processors with a camera interface unless you mean types >like the TI OMAP. This has to be a mass market cheap solution like the >Omnivision stuff. It's just that we need to interface with 10's of thousands >existing analog cameras...
Many I have seen assume a digital camera or digital datastream in VGA 'steps' of resolution, and non-interlaced format. With most you would need to convert from analog to 602 or 656 format and for CCIR/PAL set timing for non-standard 800 x 600 with borders. That is if they support the interlaced format. Some fall down on continuous video as they are meant for webcams compressing at best 10 frames per second.
>Meindert
-- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> skrev i meddelandet 
news:460e4f63$0$23099$e4fe514c@dreader12.news.xs4all.nl...
> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message > news:eujspb$ni9$1@aioe.org... >> Why not use a standard processor with camera interface? > > I don't know of any processors with a camera interface unless you mean > types > like the TI OMAP. This has to be a mass market cheap solution like the > Omnivision stuff. It's just that we need to interface with 10's of > thousands > existing analog cameras... > > Meindert > >
The AT91SAM9260 and the AP7000 has a digital camera interface but if you have signifiant volume,then one of the digital camera chips might work. The AT76C115 can do VGA 30 fps compression. Need to talk to your local Atmel representative to get NDA signed/info. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
On Saturday, in article <euls6v$im8$1@aioe.org>
     ulf@a-t-m-e-l.com "Ulf Samuelsson" wrote:

>"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> skrev i meddelandet >news:460e4f63$0$23099$e4fe514c@dreader12.news.xs4all.nl... >> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message >> news:eujspb$ni9$1@aioe.org... >>> Why not use a standard processor with camera interface? >> >> I don't know of any processors with a camera interface unless you mean >> types >> like the TI OMAP. This has to be a mass market cheap solution like the >> Omnivision stuff. It's just that we need to interface with 10's of >> thousands >> existing analog cameras...
^^^^^^^^^^^^^^^
>> >> Meindert >> > >The AT91SAM9260 and the AP7000 has a digital camera interface >but if you have signifiant volume,then one of the digital camera chips might >work.
Ulf I expected better from you, he specifically says 'existing' analog cameras. So this is to go into situations to connect to existing cameras. This is not replacing cameras situations but obviously a device to hang onto existing installations/units being sold. How is replacing existing cameras with digital cameras going to help?
>The AT76C115 can do VGA 30 fps compression.
Which if he has CCIR analog cameras (normal resolution 768x576 @ 50Hz interlaced) is going to be of little use. CCIR was mentioned in his first post.
>Need to talk to your local Atmel representative to get NDA signed/info.
These look like standard 'multimedia' phone chips, not video chips. Questions for Meindert 1/ Is this CCIR mono or RGB? 2/ What compression rate and delay are you looking for? 3/ Is the output to storage or a transmission link? 4/ What sort of compression are you looking for? You might need to look at people like LogicDevices www.logicdevices.com or more likely Averlogic www.averlogic.com. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
>> >>The AT91SAM9260 and the AP7000 has a digital camera interface >>but if you have signifiant volume,then one of the digital camera chips >>might >>work. > > Ulf I expected better from you, he specifically says 'existing' analog > cameras. > So this is to go into situations to connect to existing cameras. This is > not > replacing cameras situations but obviously a device to hang onto existing > installations/units being sold. >
Think You misunderstand... I assume that there is a way to get CCIR analogue data to a digital stream compatible with the output of a CMOS imager. This is basically data, hsync, vsync and pixel clock. If that is possible, then you can connect that datastream to a processor which can DMA to SDRAM.
> How is replacing existing cameras with digital cameras going to help?
That was not the plan...
> >>The AT76C115 can do VGA 30 fps compression. > > Which if he has CCIR analog cameras (normal resolution 768x576 @ 50Hz > interlaced) is going to be of little use. CCIR was mentioned in his first > post. >
The AT76C11x chips have a PAL output, so they are used to this type of resolution. I was really talking about compression performance. You probably need to deinterlace in S/W, not sure the CPU can handle that, but after that, it should be straightforward. VGA at 30 fps = 9,216,000 pixels per second CCIR at 25 fps (50 fps interlaced) is 11,059,200 11,059,200/9,216,000 = 1,2 so we are talking about the same order of magnitude. The VGA colour solution is probably using more bits per pixel.
>>Need to talk to your local Atmel representative to get NDA signed/info. > > These look like standard 'multimedia' phone chips, not video chips. >
No, they are optimized for digital cameras.
> Questions for Meindert > > 1/ Is this CCIR mono or RGB? > 2/ What compression rate and delay are you looking for? > 3/ Is the output to storage or a transmission link? > 4/ What sort of compression are you looking for? > > You might need to look at people like LogicDevices www.logicdevices.com > or more likely Averlogic www.averlogic.com. > > --
AVERLogics solut&#2013265933;on seems equivalent to the one provided with the 115. You have a video decoder chip, providing the digital interface which connects to a video compression IC; which is controlled by a 32 bit RISC processor. The AT76C115 integrates both the compression engine and the RISC processor. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
On Saturday, in article <eumf1i$q1i$1@aioe.org>
     ulf@a-t-m-e-l.com "Ulf Samuelsson" wrote:

>>> >>>The AT91SAM9260 and the AP7000 has a digital camera interface >>>but if you have signifiant volume,then one of the digital camera chips >>>might >>>work. >> >> Ulf I expected better from you, he specifically says 'existing' analog >> cameras. >> So this is to go into situations to connect to existing cameras. This is >> not >> replacing cameras situations but obviously a device to hang onto existing >> installations/units being sold. >> > >Think You misunderstand... >I assume that there is a way to get CCIR analogue data to a digital stream >compatible with the output of a CMOS imager. >This is basically data, hsync, vsync and pixel clock.
Which can be an interesting exercise in itself, manipulating the front ends to synchronise properly and dealing with different fields is not always handled correctly.
>If that is possible, then you can connect that datastream to a processor >which can DMA to SDRAM. > >> How is replacing existing cameras with digital cameras going to help? > >That was not the plan...
Was not obvious from what you put. Having seen various interfaces that have extreme trouble with doing this, even Sony chipset that when run at 27MHz instead of a 28 odd MHz clock and told so, just dropped off pixels to go to standard rates, without properly adjusting the data.
>>>The AT76C115 can do VGA 30 fps compression. >> >> Which if he has CCIR analog cameras (normal resolution 768x576 @ 50Hz >> interlaced) is going to be of little use. CCIR was mentioned in his first >> post. >> > >The AT76C11x chips have a PAL output, so they are used to this type of >resolution.
I have seen all sorts of 'PAL' outputs from such devices, the most common methods are VGA in PAL with ugly border or non-centred image. Let alone only display half the lines as each field but each field is the same (line doubled o/p).
>I was really talking about compression performance. >You probably need to deinterlace in S/W, not sure the CPU can handle that, >but after that, it should be straightforward.
That is quite an overhead, either in DMA manipulation or even bit blitting assisted functions. True deinterlacing has to bear in mind many factors and is better done as creating proper frames from each field seperately not by merging two fields into one frame as the mess on moving objects can be a nightmare. Many front ends do not like dealing with half lines and 'half resolution' frames and messing about. Yes I have designed circuits that have had to do this in real time, with minimal delay and artifacts, no missing frames or lines.
>VGA at 30 fps = 9,216,000 pixels per second >CCIR at 25 fps (50 fps interlaced) is 11,059,200 > >11,059,200/9,216,000 = 1,2 so we are talking about the same order of >magnitude.
50Hz is normally where most of these devices fall over, as they are designed for 60Hz VGA at best, going to 50Hz at higher res, even interlaced is often where they fall over. BTDTGTTS.
>The VGA colour solution is probably using more bits per pixel.
Sometimes, as many rely on 18bit or less full colour word. Especially if going to LCD as most colour LCDs only have a digital 18bit path.
>>>Need to talk to your local Atmel representative to get NDA signed/info. >> >> These look like standard 'multimedia' phone chips, not video chips. >> >No, they are optimized for digital cameras.
Which performance wise is geared at near real frame rate[1] for VGA resolution which for someone who has spent time doing a lot of video work, these apps using phones, multimedia and the like in 99% of cases don't care if they miss one frame in 30.
>> Questions for Meindert >> >> 1/ Is this CCIR mono or RGB? >> 2/ What compression rate and delay are you looking for? >> 3/ Is the output to storage or a transmission link? >> 4/ What sort of compression are you looking for? >> >> You might need to look at people like LogicDevices www.logicdevices.com >> or more likely Averlogic www.averlogic.com. >> >> -- > >AVERLogics solut?on seems equivalent to the one provided with the 115. >You have a video decoder chip, providing the digital interface which >connects to a video compression IC; which is controlled by a >32 bit RISC processor.
NO ONE of their reference designs includes a RISC processor for ethernet connection. On the same page you were looking at there is a reference design for a Cypress USB device add on instead for USB connection. Not a 32bit RISc, when adding ethernet for many it is easier to get simple 23bit processor with built in controller, especially for 100baseT support, which if not there people baulk at. Their devices are meant for interlaced video from the outset not by software manipulation and overhead. The ethernet and USB reference designs are what are refered to as marketing/management level reference designs to get buy in from others. Especially those who want something quick and expect it quick because they don't understand it, but expect broadcast video from a mobile phone camera. BTDTGTTS
>The AT76C115 integrates both the compression engine and the RISC processor.
Apples and Pears. [1] near real frame rate VGA is a bit of a misnomer as most try to do NTSC frame rate as non-interlaced so they achieve 640x480 @30Hz to 'match' NTSC interlaced at 60Hz. This can be quite evident in moving objects between frames, that do not have to move very far or fast, before give all sorts of nasties. Hence 'multimedia' not video devices classification. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate