Re: Video capture/compression
- From: paul$@pcserviceselectronics.co.uk (Paul Carpenter)
- Date: Sat, 31 Mar 2007 21:52:18 +0100 (BST)
On Saturday, in article <eumf1i$q1i$1@xxxxxxxx>
ulf@xxxxxxxxxxxxx "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.
No, they are optimized for digital cameras.Need to talk to your local Atmel representative to get NDA signed/info.
These look like standard 'multimedia' phone chips, not video chips.
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@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<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
.
- Prev by Date: Re: Best processors for trig?
- Next by Date: Re: shame on MISRA
- Previous by thread: Re: Best processors for trig?
- Next by thread: Re: shame on MISRA
- Index(es):
Relevant Pages
|
