Maker Pro
Maker Pro

Video overlay generator

Hi!

Im starting a design process for a utility that needs to implement a
video overlay generator. Previously we've been using the "classic"
STV5730-chip for text-overlay but since this IC is quite outdated and
hard to get hands on we've decided to implement our own overlay
generator.
The reason for this is that we want to be able to display graphical
items(such as a customer logo) and also because we need delecate
control of synchronization signals.
The video signal is CVBS in/out and could be either PAL or NTSC.
We've thought of using these three major parts to implement the
design: a video decoder (f.e. Texas Instruments TVP5150) that feeds a
digital video stream into a FPGA (f.e. Xilinx's Spartan 3), that
performs blending between the digital video stream and a "overlay
buffer" that gets generated from a microcontroller, and finally into a
video encoder (f.e. Analog Devices ADV7171).

I would really appreciate some feedback or input to this solution if
someone out there has done something similar.

Should I count with a noticeable video quality loss due to the AD ->
DA conversion?

Our application has some specific requirements, f.e. there is a frame
counter that has to be updated each frame which probably will require
us to implement a character generator inside the FPGA.

Do you think this is a viable solution - is there any existing ICs
that will do some or most of this work for me?

Best regards,
Andreas Eriksson
 
A

Andreas

Jan 1, 1970
0
Hi!

Im starting a design process for a utility that needs to implement avideooverlaygenerator. Previously we've been using the "classic"
STV5730-chip for text-overlaybut since this IC is quite outdated and
hard to get hands on we've decided to implement our ownoverlay
generator.
The reason for this is that we want to be able to display graphical
items(such as a customer logo) and also because we need delecate
control of synchronization signals.
Thevideosignal is CVBS in/out and could be either PAL or NTSC.
We've thought of using these three major parts to implement the
design: avideodecoder (f.e. Texas Instruments TVP5150) that feeds a
digitalvideostream into a FPGA (f.e. Xilinx's Spartan 3), that
performs blending between the digitalvideostream and a "overlay
buffer" that gets generated from a microcontroller, and finally into avideoencoder (f.e. Analog Devices ADV7171).

I would really appreciate some feedback or input to this solution if
someone out there has done something similar.

Should I count with a noticeablevideoquality loss due to the AD ->
DA conversion?

Our application has some specific requirements, f.e. there is a frame
counter that has to be updated each frame which probably will require
us to implement a character generator inside the FPGA.

Do you think this is a viable solution - is there any existing ICs
that will do some or most of this work for me?

Best regards,
Andreas Eriksson

No suggestions?

Best regards,
Andreas Eriksson
 
F

Frank Raffaeli

Jan 1, 1970
0
No suggestions?

Best regards,
Andreas Eriksson

Most of the loss will be in the chroma-luma separation. If you can
somehow overlay a simple color graphic by replacing the video with the
overlay (like an OSD), then you can pass-through the CVBS and only
change the signal where the overlay is.

The reason video / audio decoders are going out of style is because
now they're all custom ASICs. Even for analog signals.

Frank
 
M

MooseFET

Jan 1, 1970
0
Hi!

Im starting a design process for a utility that needs to implement a
video overlay generator. Previously we've been using the "classic"
STV5730-chip for text-overlay but since this IC is quite outdated and
hard to get hands on we've decided to implement our own overlay
generator.
The reason for this is that we want to be able to display graphical
items(such as a customer logo) and also because we need delecate
control of synchronization signals.
The video signal is CVBS in/out and could be either PAL or NTSC.
We've thought of using these three major parts to implement the
design: a video decoder (f.e. Texas Instruments TVP5150) that feeds a
digital video stream into a FPGA (f.e. Xilinx's Spartan 3), that
performs blending between the digital video stream and a "overlay
buffer" that gets generated from a microcontroller, and finally into a
video encoder (f.e. Analog Devices ADV7171).

I would really appreciate some feedback or input to this solution if
someone out there has done something similar.

This sounds to me like a very bad way to go. Don't meddle with the
signal for the normal picture. Only produce a "difference value" in
your circuits. This way, your DAC and ADC aren't going to mess up the
video and you have a much simpler processing job to do.

A multiplying DAC can control the amount of normal video you pass and
a second DAC can set the amount you add or subtract. The one I was
involved in many years ago just used a couple of transistors as
switches. One switch shifted the incoming video towards the white by
cutting down the gain and the other added signal.

A PLL is needed to lock your timing to the video. It doesn't have to
be super good but without it, the edge of the inserted text flickers.
 
Most of the loss will be in the chroma-luma separation. If you can
somehow overlay a simple color graphic by replacing the video with the
overlay (like an OSD), then you can pass-through the CVBS and only
change the signal where the overlay is.

The reason video / audio decoders are going out of style is because
now they're all custom ASICs. Even for analog signals.

Frank

Yes, this is very possible, I have done it with some simple analog
switches (HC4053).
In case of color, you also need to insert the right chroma phase, that
means in PAL
that you need to phase lock a 4.43 MHz xtal and get the H/2 info too,
apart
from the H PLL and V sync.
And, depending on how you create the chroma phase, also 2 90 degrees
shifted apart
modulators.
It is all low power analog stuff, could easily fit on one board, if
the graphics is fixed
(for example a logo) you could clock from an EPROM (via a PLL locked
clock to H), or else use SRAM and provide some processor on with an
interface
to update the SRAM.
The digital crude way would be to digitize, add you graphics, and make
analog
again, using a high end PC for enough speed to do it in real time.
Both methods likely require some programming knowledge too.
What method depends on quality required and power available, knowledge
of video
basics.... time, money.... what not.
 
M

MooseFET

Jan 1, 1970
0
On 15 aug, 14:34, Frank Raffaeli <[email protected]> wrote:

[....Video overlay...]
Yes, this is very possible, I have done it with some simple analog
switches (HC4053).

You don't want to use a HC4053. They switch very quickly. This makes
frequencies up into the chroma carrier frequency. You want a softer
switching so that you stop short of that.

In case of color, you also need to insert the right chroma phase, that
means in PAL
that you need to phase lock a 4.43 MHz xtal and get the H/2 info too,
apart
from the H PLL and V sync.

You want to go up to 4 times the normal frequency. It is still low
enough that HC counters will work and you can get you phase shifted
components by using a Johnson counter.


[...]
It is all low power analog stuff, could easily fit on one board, if

I've seen boards up to 12 x 18 inches. You are right it is small but
perhaps you should have used a different way to express it.
 
J

Jan Panteltje

Jan 1, 1970
0
On 15 aug, 14:34, Frank Raffaeli <[email protected]> wrote:

[....Video overlay...]
Yes, this is very possible, I have done it with some simple analog
switches (HC4053).

You don't want to use a HC4053. They switch very quickly. This makes
frequencies up into the chroma carrier frequency. You want a softer
switching so that you stop short of that.

Well, this is not the case in _my_ case.
I used it to add text (and colored text).
When you use a slow chip, like the old CD4053, there is a _MUCH_ to long
switching delay, causing visible artefacs eben in BW video.

I _had_ to use the HC4053.
Used the circuit to add subtitles to VHS recordings before the digital
video times.

Some company in Amsterdam asked me if I could add colored subs that way,
so I made some experimental setup, it worked.
But they did not order it...

As to frequencies in the chroma range, sure, but there is a bit more to adding
for example text, like lead delay and tail delay (character outline),
I created those delays with some counters (say shift registers) and fast clock.
Would have to look it up for the details.
But if chroma bothered you, then for example you could perhaps decide to swith on zero
crossing of the inserted chroma.
You _MUST_ switch within a fraction of chroma period, say well below 10 nS.

Personally I am glad all that analog is gone, and all is digital now.
The quality is much better, and procesing is much easier, just programing.

If the guy just wanted _simple_ BW graphics and text he should use something like
a SAA5246A, its does 25 lines of 40 characters in genlock on a composite signal
PAL or NTSC.
If you wanted to add outline and color you would need more stuff,
the SAA has an RGB output you could use though.

In most cases SAA5246A will be sufficient, if you can still get one.
 
M

MooseFET

Jan 1, 1970
0
[....Video overlay...]
Yes, this is very possible, I have done it with some simple analog
switches (HC4053).
You don't want to use a HC4053. They switch very quickly. This makes
frequencies up into the chroma carrier frequency. You want a softer
switching so that you stop short of that.

Well, this is not the case in _my_ case.
I used it to add text (and colored text).
When you use a slow chip, like the old CD4053, there is a _MUCH_ to long
switching delay, causing visible artefacs eben in BW video.

The circuit I was involved in used a descrete transistor to do the
switching. Actually there were two transistors. One shifted
everything towards the white and the other adding the text.

[....]
As to frequencies in the chroma range, sure, but there is a bit more to adding
for example text, like lead delay and tail delay (character outline),
I created those delays with some counters (say shift registers) and fast clock.
Would have to look it up for the details.

IIRC, the delay was one pixel of the inserted text.
But if chroma bothered you, then for example you could perhaps decide to swith on zero
crossing of the inserted chroma.

This would not work IMO. If the picture happened to have its chroma
at its peak at the time you switched, you would still create artifacts
at the edges.
 
J

Jan Panteltje

Jan 1, 1970
0
The circuit I was involved in used a descrete transistor to do the
switching. Actually there were two transistors. One shifted
everything towards the white and the other adding the text.

.....
Yes there are as many ways to do that as there are semiconductors.

This would not work IMO. If the picture happened to have its chroma
at its peak at the time you switched, you would still create artifacts
at the edges.

Any color change in NTSC and PAL has some artefacts.
The color bandwith is less then the BW bandwidth.
Look at a color bar, it does just that.
If you cut half a chroma period to zero at the top, then there would only be higher
harmonics, double or more then the Fc, so 8.86 MHz in PAL, and way outside the video-band,
An output lowpas (and likely any following equipment that accepts the FBAS) would remove that.

But yes, digital is better, and if you must you can do digital RGB processing (as opposed to YUV).
But then we are miles away from the simple solution the OP probably wants.
 
J

Jan Panteltje

Jan 1, 1970
0
On a sunny day (Thu, 16 Aug 2007 15:30:43 GMT) it happened Jan Panteltje

Actually here is how I inserted the characters (horizontal timing):
---
| |
| |
------------- ------- character dot

-
| |
| |
---------- ------------ leading outline pulse

-
| |
| |
----------------- -------- trailing outline pulse


------------|||||----------- new chroma for character

||||||||||---------|||||||||| old chroma form picture

The leading and trailing outline pulses are black or grey level (trimpot),
those cause better visibility of the characters in a live background.
Else for example white characters disappear in white background.

The 'leading' pulse is in fact generated clocking one or more
steps from the main pulse, the main pulse is delayed that much in a shift
register, and after the main pulse ends, the trailing pulse is generated.
You can get fancy by adding one line delay lines to make a vertical
outline too.

As you have the outline pulse remove chroma and video from the original,
you can, by selecting the best pulse width for these, avoid color problems.
 
M

MooseFET

Jan 1, 1970
0
....
Yes there are as many ways to do that as there are semiconductors.

I quite agree. In principle, you could build the whole thing from
2N2222s and 1K resistors if you used enough of them.

[....]
Any color change in NTSC and PAL has some artefacts.
The color bandwith is less then the BW bandwidth.

Yes. The things I was refering to was the funny colors at the edge.
When we had the switching wrong, the color would change instead of
fading towards a lower saturation and back. It usually wasn't too bad
but on strong colors it somethings looked funny.

More on the self follow up.
 
M

MooseFET

Jan 1, 1970
0
On a sunny day (Thu, 16 Aug 2007 15:30:43 GMT) it happened Jan Panteltje

Actually here is how I inserted the characters (horizontal timing):
---
| |
| |
------------- ------- character dot

-
| |
| |
---------- ------------ leading outline pulse

-
| |
| |
----------------- -------- trailing outline pulse

------------|||||----------- new chroma for character

||||||||||---------|||||||||| old chroma form picture

The leading and trailing outline pulses are black or grey level (trimpot),
those cause better visibility of the characters in a live background.
Else for example white characters disappear in white background.

The 'leading' pulse is in fact generated clocking one or more
steps from the main pulse, the main pulse is delayed that much in a shift
register, and after the main pulse ends, the trailing pulse is generated.
You can get fancy by adding one line delay lines to make a vertical
outline too.

The outline on the one I worked on was just an extra row of pixels.
It really wasn't an outline so much as a shift to a lower saturation
and brighter. The character's dots were darkened from that level.
The font table, IIRC, was and even power of two tall but the actual
characters within it were less than that.
 
J

Jan Panteltje

Jan 1, 1970
0
The outline on the one I worked on was just an extra row of pixels.
It really wasn't an outline so much as a shift to a lower saturation
and brighter. The character's dots were darkened from that level.
The font table, IIRC, was and even power of two tall but the actual
characters within it were less than that.

Yes, but then you have already a font with outline, and add in an analog way.
On chips like the SAA5246A the font has no outline (but you can make a black
background) so you have to add it yourself.
When we go back to the fifties (last century) in my country the subtitles
for the TV programs were printed on IBM type punch cards, a little camera was
reading these, edges sharpend, clipped, and delay lines (analog delay lines!)
were used to add the character outlines.
A man pushed a button in real time, anytime a new title (=card) was needed.

We have come a long way since that.

I have my own software now to add subs the digital way:
http://panteltje.com/panteltje/subtitles/index.html
It is GPL'd so anyone can use it.
 
M

MooseFET

Jan 1, 1970
0
On a sunny day (Thu, 16 Aug 2007 18:04:05 -0700) it happened MooseFET [....]
The outline on the one I worked on was just an extra row of pixels.
It really wasn't an outline so much as a shift to a lower saturation
and brighter. The character's dots were darkened from that level.
The font table, IIRC, was and even power of two tall but the actual
characters within it were less than that.

Yes, but then you have already a font with outline, and add in an analog way.
On chips like the SAA5246A the font has no outline (but you can make a black
background) so you have to add it yourself.

If the FPGA route was taken by the OP, I'd suggest building the
outlining into the font. It has the advantage that you can code the
7FH characters without the outline like the box drawing characters on
the IBM PC.
When we go back to the fifties (last century) in my country the subtitles
for the TV programs were printed on IBM type punch cards, a little camera was
reading these, edges sharpend, clipped, and delay lines (analog delay lines!)
were used to add the character outlines.
A man pushed a button in real time, anytime a new title (=card) was needed.

We have come a long way since that.

Have we really. When I turn off the sound on my TV, the closed
captioning turns on. For many programs and ads the closed captioning
reads like this:

@A@A@A@A@A@A@A@######@A@A@VA##A@A@A@A@A

-next scene-

$$$$$$$$%%%%%$$$$^^^^^^%%%$$$$^^^^^

-next scene-

&&&&*******@A@A@AHHHHHHHHHHHHH

.... and so on. It also leaves the aption up through several ads. It
is sometimes leaves ones up that can be read from one ad into the
next. This means that the car leaves your hair clean and shiny.

I have my own software now to add subs the digital way:
http://panteltje.com/panteltje/subtitles/index.html
It is GPL'd so anyone can use it.

Even though it is very unlikely that I will use it, I will thank you
for adding that to what is available. In the unlikely event that I do
need to do inserted text again, I will look it up.
 
J

Jan Panteltje

Jan 1, 1970
0
If the FPGA route was taken by the OP, I'd suggest building the
outlining into the font. It has the advantage that you can code the
the IBM PC.


Have we really. When I turn off the sound on my TV, the closed
captioning turns on. For many programs and ads the closed captioning
reads like this:

@A@A@A@A@A@A@A@######@A@A@VA##A@A@A@A@A

-next scene-

$$$$$$$$%%%%%$$$$^^^^^^%%%$$$$^^^^^

-next scene-

&&&&*******@A@A@AHHHHHHHHHHHHH

... and so on. It also leaves the aption up through several ads. It
is sometimes leaves ones up that can be read from one ad into the
next. This means that the car leaves your hair clean and shiny.

Yes, that can be confusing ;-) hehe.
I see you are in the US, in Europe we have Ceefax / teletext,
it looks like this in overlay:
http://en.wikipedia.org/wiki/Teletext
This is actually what SAA5246A output in RGB looks like
(circuits are build in almost all analog TVs here).
It is a very useful service, and can be used for subtitles too,
in that case you only have some text at the bottom, with a dark background
overlaying the picture.
Things that are carried are the program schedules, news, weather etc.
About 800 pages of text refreshed every minute, the signal is send
in the vertical blanking.
Now digital has come, Ceefax or teletext or Videotext (German) is
just a substream in the digital transport stream, the service remains active,
although BBC and some other UK stations no longer have it it seems.
Maybe because it is free it never took of in the US?
They have all sorts of adds here too that people can place on the local station.
There are several PC versions too, in case a TV card is in the PC,
or an external decoder, mine displays 4 pages at the time:
http://panteltje.com/panteltje/xkrs/xkrs.jpg

Even though it is very unlikely that I will use it, I will thank you
for adding that to what is available. In the unlikely event that I do
need to do inserted text again, I will look it up.

You are welcome.
 
A

Andreas

Jan 1, 1970
0
First of all, thanks a lot for the interesting discussion - at first I
thought there would be no response, but after two days I find more
than 10!

Second, I would like to point out my view on going the FPGA-route.

Using a FPGA+encoder+decoder seem to make a very flexible solution - I
have almost all possible overlay techniques available, I could f.e.
implement a alpha blending routine, vary the overlay resolution very
easily and I should be able to not worry as much about flickering
edges or trimming color/white levels.

The cost of the system is not primary, rather reliability and picture
quality.

The main concern of this route is that I'm not sure how much
degradation of the video quality is to be expected(although there
certainly are other factors like routing to take into consideration).

Also, I'm more of a digital/firmware-guy so I feel "safer" knowing
that I can control a lot more by firmware and HDL.

The analog switching route also is interesting, but I feel a whole lot
more uncertain in how to implement such a circuit reliably.
Are there any "modern" (not to be obsoleted in the next year or so)
circuits that are more suitable for this task that I should look for,
or have reference designs that share my application?

Best regards,
Andreas Eriksson
 
F

Frank Raffaeli

Jan 1, 1970
0
First of all, thanks a lot for the interesting discussion - at first I
thought there would be no response, but after two days I find more
than 10!

Second, I would like to point out my view on going the FPGA-route.

Using a FPGA+encoder+decoder seem to make a very flexible solution - I
have almost all possible overlay techniques available, I could f.e.
implement a alpha blending routine, vary the overlay resolution very
easily and I should be able to not worry as much about flickering
edges or trimming color/white levels.

The cost of the system is not primary, rather reliability and picture
quality.

The main concern of this route is that I'm not sure how much
degradation of the video quality is to be expected(although there
certainly are other factors like routing to take into consideration).

Also, I'm more of a digital/firmware-guy so I feel "safer" knowing
that I can control a lot more by firmware and HDL.

The analog switching route also is interesting, but I feel a whole lot
more uncertain in how to implement such a circuit reliably.
Are there any "modern" (not to be obsoleted in the next year or so)
circuits that are more suitable for this task that I should look for,
or have reference designs that share my application?

Best regards,
Andreas Eriksson
I agree you will have better control with HDL, depending upon the
source of the video. So you're going to convert the CVBS to digital
including the chroma sub-carrier? I've never seen it done this way,
but it can work if you sample fast enough (~40 MSPS for a PAL signal,
at 12 bits) if you are concerned about fidelity. You can get away with
sampling 4X the chroma, but you can't avoid some analog processing ...
such as clamping the signal - e.g. maintaining the DC component.

The most difficult part might be the digital PLL. You will need to
generate the chroma signal, assuming you need a color, not B&W
overlay. A 32-bit NCO is probably enough. If your video is from a
skewed time-base like a VCR, then you probably need to demodulate the
chroma and correct the time-base first.

If the time-base is clean, like *most* broadcast video, then you can
get away with sampling the CVBS, re-generating the color sub-carrier
with a DPLL, and "softly" inserting the signal digitally. If you use a
lower sampling rate like 4x chroma, then the sample clock needs to be
synchronous with the horizontal scan rate.

Frank
 
M

MooseFET

Jan 1, 1970
0
On a sunny day (Fri, 17 Aug 2007 06:26:01 -0700) it happened MooseFET [.....]
-next scene-

-next scene-

... and so on. It also leaves the caption up through several ads. It
is sometimes leaves ones up that can be read from one ad into the
next. This means that the car leaves your hair clean and shiny.

Yes, that can be confusing ;-) hehe.

The floor clean does leave your hair clean and shiny BTW.
I see you are in the US, in Europe we have Ceefax / teletext,
it looks like this in overlay:
http://en.wikipedia.org/wiki/Teletext

Does it always completely take of the video or can it leave a dimmed
version of the picture behind the text? One of the things I don't
like about the system is that it covers part of the screen and you
loose objects that travel into that area.


[....]
It is a very useful service, and can be used for subtitles too,
in that case you only have some text at the bottom, with a dark background
overlaying the picture.
Things that are carried are the program schedules, news, weather etc.
About 800 pages of text refreshed every minute, the signal is send
in the vertical blanking.

Such things would never be allowed in the US. It is the law here that
at least 83% of what is refered to as news must either be advertizing
of programs or reports about Paris Hilton.

Now digital has come, Ceefax or teletext or Videotext (German) is
just a substream in the digital transport stream, the service remains active,
although BBC and some other UK stations no longer have it it seems.
Maybe because it is free it never took of in the US?

In the US, networks are strickly a for profit business. The US, PBS
system is nowhere near the BBC. If you watch a 1.5 hour movey on US
TV, it usually takes 2 hours to watch it. They cut them down to make
time for even more ads.
 
J

Jan Panteltje

Jan 1, 1970
0
Does it always completely take of the video or can it leave a dimmed
version of the picture behind the text?

It can show the picture at the same time.
One of the things I don't
like about the system is that it covers part of the screen and you
loose objects that travel into that area.

It is standard some buttons on the TV remote, so making
it appear and go is just a button press.
The remote has also buttons to select a page number, and
'reveal' - 'conceal', showing hidden text parts.
Such things would never be allowed in the US. It is the law here that
at least 83% of what is refered to as news must either be advertizing
of programs or reports about Paris Hilton.

mm thought she went to jail some time ago, but yes, I have noticed
a lot of preference treatment for her :)

I guess (entering politics) that Hilton is there to draw attention
away from the 4000 funerals of volunteer soldiers.
 
I agree you will have better control with HDL, depending upon the
source of the video. So you're going to convert the CVBS to digital
including the chroma sub-carrier? I've never seen it done this way,
but it can work if you sample fast enough (~40 MSPS for a PAL signal,
at 12 bits) if you are concerned about fidelity. You can get away with
sampling 4X the chroma, but you can't avoid some analog processing ...
such as clamping the signal - e.g. maintaining the DC component.

The most difficult part might be the digital PLL. You will need to
generate the chroma signal, assuming you need a color, not B&W
overlay. A 32-bit NCO is probably enough. If your video is from a
skewed time-base like a VCR, then you probably need to demodulate the
chroma and correct the time-base first.

If the time-base is clean, like *most* broadcast video, then you can
get away with sampling the CVBS, re-generating the color sub-carrier
with a DPLL, and "softly" inserting the signal digitally. If you use a
lower sampling rate like 4x chroma, then the sample clock needs to be
synchronous with the horizontal scan rate.

Frank

Is it really necessary to go to the trouble of converting CVBS
directly to digital with a high speed ADC? My approach would be to
find a circuit to decode from CVBS to digital YCbCr or RGB, inject the
overlay information, and then re-encode back to CVBS using a video
display circuit. Would the degradation in video quality due to
decoding and re-encoding really be noticeable?

Pure analog overlay injection could better preserve the video quality,
but is the complexity of preserving the color integrity worth it? The
Obsolete Motorola MC1378 "Color Television Composite Video Overlay
Synchronizer" would simplify this task if it were still produced
(http://www.directics.com shows some inventory of these devices).

-- David
 

Similar threads

B
Replies
10
Views
2K
Fred Ferd.
F
S
Replies
1
Views
2K
Steve Dahlqvist
S
B
Replies
14
Views
2K
Jan Panteltje
J
Top