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
Reply by Ulf Samuelsson●March 31, 20072007-03-31
>>
>>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�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
Reply by ●March 31, 20072007-03-31
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
Reply by Ulf Samuelsson●March 31, 20072007-03-31
"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
Reply by ●March 31, 20072007-03-31
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.
"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
Reply by Ulf Samuelsson●March 30, 20072007-03-30
"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
>
>
Reply by 4MLA1FN●March 30, 20072007-03-30
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?
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