Video ADC

[h200]

Hi.

I'm planning to build one simple schematics / device which will convert
analog video signal to digital. The analog video signal comes from
camera over bnc and it has PAL / RGB format.

Could this kind of chip do the job :

http://www.ti.com/lit/gpn/tvp7000

or

http://www.analog.com/en/analog-to-...dv7181c/products/product.html#product-samples

 

[h200]

Do you mean PAL or RBG format? Most cameras produce composite video ie
PAL or NTSC and not RGB.

If the former there are many cheap decoders. Digkey has the TVP5150 at
£4.47 for one-off though I have never used it. I currently use a
Techwell TW9900.

Decoders accepting RGB inputs are less common, probably since they
require 2 ADCs like the ones you mention.

---------------
You are correct, PAL is mostly used and I will take this as base.
I was thinking to take any analog camera, maybe some cctv camera,
connect the BNC output of this camera to my portable device and transfer
the data over rf. Maximum distance is around 20 meters.

Camera --> video ADC ---> RF transfer ---> video DAC ----> monitor/ TV.

I can not use USB because this should be some kind of camera adapter an
it has to be portable.

TW9900 looks like very good solution.
What do you think, can i use it in my project ?

 

[h200]

There are some cheap video transmitters and receivers that would do
precisely what you want without recourse to the digital domain.

Why does it need to be so complicated?

 

[h200]

Most video decoders are simple to use and fairly forgiving. They are
all much of a muchness. The TW9910 will do the job of converting a
composite video input into 8 bit parallel YUV 4:2:2 data with embedded
syncs. All you need is attach a crystal and set the device up through a
I2C interface.

I feel Decoding/conversion is the easy bit. How were you going to
transmit this with RF over 20 metres? Have you calculated the data rates?

------------------------------------------------------------------------
OK. I will use TW900 as ADC.
How would you construct the DAC part ?

I didn't calculated the data rates but i was planning to do this after
i'v done the ADC / DAC part. You see, the transmit part should be fully
adaptable to all kind of transfer options.

 

[whit3rd]

because i want to upgrade this project in the future.

The PAL composite format is intended to be simple to transmit/receive
over RF carriers. So, why convert it to something digital, which is NOT
simple to transmit/receive? Put your PAL decoding at the
endpoint, not the origin, of the RF transmission.

Digital transmission over RF is very noise-sensitive, and the kind of
error-correction that digital TV does nowadays is beyond the
scope of most 'project' work.

 

[h200]

The PAL composite format is intended to be simple to transmit/receive
over RF carriers. So, why convert it to something digital, which is NOT
simple to transmit/receive? Put your PAL decoding at the
endpoint, not the origin, of the RF transmission.

Digital transmission over RF is very noise-sensitive, and the kind of
error-correction that digital TV does nowadays is beyond the
scope of most 'project' work.

 

[[email protected]]

Simple modulation systems are actually multipath sensitive, even if
the average field strength is quite high.

For this reason DMT/COFDM systems are typically used.

For a point-to-point link with direct line of sight (LOS) path, the
laser is a good solution and it might be enough to amplitude modulate
the laser with the baseband signal. However, this requires that the
transmitting laser is aimed _exactly_ towards the receiver, thus. any
portable/mobile applications are more or less out of the question.

 

[Nico Coesel]

I'd convert the video to streaming MPEG so you can transport it
anywhere you want. Wireless? No problem, just setup a Wifi bridge.

 

[h200]

I'd convert the video to streaming MPEG so you can transport it
anywhere you want. Wireless? No problem, just setup a Wifi bridge.

---------------
I was thinking about streaming MPEG but i dont know if this could be the
solution. Maybe it cauld be because this is standard for something like
this.

I dont want to use WIFI. There are bunch of problems regarding this kind
of transfer. I'm in cctv security line of work and trust me,
wifi is not something that you want to use. Of course there are some
quality solutions but they cost like hell.

Back to the subject

What kind of video ADC and video DAC would you use to make the encoding
/ decoding ?

TW9900 is for me still the best solution for video ADC but i dont know
how to decode this digitalized signal.

 

[[email protected]]

Try some math, for a 720 x 576 RGB picture at 25 fps that is 8 bit deep, you need:
720 x 576 x 3 x 25 = 3,110,400 bytes per second, makes 248,832,000 bits per second

A 248 MHz wide radio channel.
Sending YUV is a bit less (1.5 x) and JPEG is also better.
JPEG is better for security as it has no motion blur (each frame is sharp).

While in an uncompressed format, loosing a few pixels, perhaps some
lines or even a whole frame is no big deal, since the next frame will
contain valid data, hiding any transmission errors.

However, in any delta-modulated systems (such as JPEG) loosing some
pixels will propagate along the line. In MPEG, any bit errors in the
I-frame will propagate through the P and B frames (typically 0.5 s).

Thus, in an uncompressed (analog/digital) video stream some random
errors are acceptable, however, if you are going to use some
compressed format, a 100 % reliable transmission path is required
(such as TCP), but of course, the latencies can be anything.

 

[Ralph Barone]

Try some math, for a 720 x 576 RGB picture at 25 fps that is 8 bit deep, you need:
720 x 576 x 3 x 25 = 3,110,400 bytes per second, makes 248,832,000 bits per second

A 248 MHz wide radio channel.
Sending YUV is a bit less (1.5 x) and JPEG is also better.
JPEG is better for security as it has no motion blur (each frame is sharp).

A 248 MHz wide radio channel is not in your country or on earth unless you go THz,
and then the distance sucks.
And that is just as easy to jam from a security POV as WiFi.
I run 2 WiFi security cams, and it works perfectly.
With jpeg compression you get at most 20 fps over normal WiFi.
Modern webcams already compress to H264 or some variant of mpeg.

Only wired is sort of safe for security, but then they do other things(tm) to it.
All depends on what you want to protect.


That was 1000$ advice, now go to sleep and tomorrow think of some other thing.

One Hz of bandwidth is not required to transmit 1 bps of information. It
all depends on your SNR.

 

[Nico Coesel]

---------------
I was thinking about streaming MPEG but i dont know if this could be the
solution. Maybe it cauld be because this is standard for something like
this.

I dont want to use WIFI. There are bunch of problems regarding this kind
of transfer. I'm in cctv security line of work and trust me,
wifi is not something that you want to use. Of course there are some
quality solutions but they cost like hell.

I doubt some self made solution is going to cut it if you want low
cost. Developments costs can rise quickly. If cost is an issue I'd go
for commercially available network camera's with Wifi like the ones
from Axis. Proprietary wireless connections are prone to jamming
without people knowing it. If someone jams the wifi frequencies it
will get noticed.

Come to think of it. AFAIK one of my customers sells a high resolution
(several Mpixels) wifi or wired security camera which records video
and audio locally if the connection is not available. They also have a
central storage facility where people can access the recordings
through internet. Its a pretty neat package and relatively low cost.

What kind of video ADC and video DAC would you use to make the encoding
/ decoding ?

TW9900 is for me still the best solution for video ADC but i dont know
how to decode this digitalized signal.

Like others pointed out: if you don't know about the wireless link
then it is no use to look into coding/decoding. Besides that PAL
signals are already intended to be transferred over wired and wireless
connections. I'd concentrate on transferring PAL over wirelles or
wired connections. This is old and well known technology.

 

[h200]

Oops:
Try some math, for a 720 x 576 RGB picture at 25 fps that is 8 bit deep, you need:
720 x 576 x 3 x 25 = 31,104,000 bytes per second, makes 248,832,000 bits per second
^^
dropped a zero

----------------
Let's forget about the transfer... for now.

How would you make the encoding / decoding part.
From my pov TW9900 would be the best solution but how to make decoding.
Do you now some HW solutions that use MPEG as base for ADC ?

 

[Nico Coesel]

While in an uncompressed format, loosing a few pixels, perhaps some
lines or even a whole frame is no big deal, since the next frame will
contain valid data, hiding any transmission errors.

However, in any delta-modulated systems (such as JPEG) loosing some
pixels will propagate along the line. In MPEG, any bit errors in the
I-frame will propagate through the P and B frames (typically 0.5 s).

Thus, in an uncompressed (analog/digital) video stream some random
errors are acceptable, however, if you are going to use some
compressed format, a 100 % reliable transmission path is required
(such as TCP), but of course, the latencies can be anything.

Thats not entirely true. H264/MPEG based transmission systems like the
ones used for DVB-T allow some errors without distorting the entire
frame.

 

[Nico Coesel]

----------------
Let's forget about the transfer... for now.

How would you make the encoding / decoding part.
From my pov TW9900 would be the best solution but how to make decoding.
Do you now some HW solutions that use MPEG as base for ADC ?

You can connect the output of the TW9900 to a SoC (chip with ARM cpu
and peripherals) and use that to encode the video stream into MPEG for
transfer over a network or decode/scale it for displaying on a screen
(direct LCD panel connection, RGB analog, VGA, composite or HDMI).
Most SoCs have hardware accellerators to do this. You don't need a
state of the art SoC to do this. It will require some software
(Linux).

 

[[email protected]]

Same for jpeg (moption jpeg only uses that one pictrure, it is just a stream of jpeg pictures)!



No, you are confused with mpeg h264 liek systems where you have a whole frame transmitted only very so often

For JPEG with 8x8 DCT block, a corrupted low order coefficient will
corrupt the whole 8x8 block, with clear visual impact. A corrupted
high order coefficient will have much less visual impact, since the
error will appear as high frequency low amplitude noise across the 8x8
block.

 

[josephkk]

I still have a considerable stock of an old Conexant video encoder which
is now obsolete. So I'm afraid until these are exhausted I'm not going
to be much good when it comes to sourcing alternative video encoders.

All I can suggest is have a look at Digikey or equivalent for video
encoders.

Have a link to a data sheet?

?-)

 

[josephkk]

You can do that analog as well. OK, they were fiber optic. Want some old
model numbers?

?-)

 

[josephkk]

Simple modulation systems are actually multipath sensitive, even if
the average field strength is quite high.

For this reason DMT/COFDM systems are typically used.

For a point-to-point link with direct line of sight (LOS) path, the
laser is a good solution and it might be enough to amplitude modulate
the laser with the baseband signal. However, this requires that the
transmitting laser is aimed _exactly_ towards the receiver, thus. any
portable/mobile applications are more or less out of the question.

That will work, but for more free space applications i would put an FM
modulated carrier to the laser. Several advantages. For that matter,
even for FO connections.

?-)

 

[josephkk]

---------------
I was thinking about streaming MPEG but i dont know if this could be the
solution. Maybe it cauld be because this is standard for something like
this.

I dont want to use WIFI. There are bunch of problems regarding this kind
of transfer. I'm in cctv security line of work and trust me,
wifi is not something that you want to use. Of course there are some
quality solutions but they cost like hell.

Back to the subject

What kind of video ADC and video DAC would you use to make the encoding
/ decoding ?

TW9900 is for me still the best solution for video ADC but i dont know
how to decode this digitalized signal.

There isn't much "decode" at that point; is nearly raw digitized SMPTE-170
at that point, shove it to an appropriate video DAC and it is analog
again. Well there are some caveats here, but if you understand the tech
it is nearly this simple.

MPEG-2 and MPEG-4 and h.264 IP cameras are readily available from a bunch
of vendors, why deal with the compression in your own hardware except as a
learning exercise?

?-)