Video switching signals
Gennady
Posts: 34
Hi,
I need to insert (not overlay) text with border into external video. Put syncronizing aside, for this purpose I need to get character and border signals·to use with with external switches.
With TV output it's tough (as I see it). RGB out is a lot easier - just to make characters, border and background of R,G or B colors.
Since I don't need to generate synch, is it possible to generate RGB characters with tv timing? Has anybody tried it?
Also the only way to generate border I see now is to build a custom font (HUGE RAM waste·
·).
I don't want to use graphics characters - they don't look as nice as text based.
Any alternative idea of a border generation for characters ?
Gennady·
I need to insert (not overlay) text with border into external video. Put syncronizing aside, for this purpose I need to get character and border signals·to use with with external switches.
With TV output it's tough (as I see it). RGB out is a lot easier - just to make characters, border and background of R,G or B colors.
Since I don't need to generate synch, is it possible to generate RGB characters with tv timing? Has anybody tried it?
Also the only way to generate border I see now is to build a custom font (HUGE RAM waste·
·).I don't want to use graphics characters - they don't look as nice as text based.
Any alternative idea of a border generation for characters ?
Gennady·
Comments
2) What kind of border do you want ... some kind of pattern? ... a pure color of some kind? If you can use a tiled driver for the video, then the same 16 x 16 tile can repeat along most of the border and you'd only some variation at the edges and corners. You might only need 16 or 32 tiles and the rest of the characters can come from the ROM font.
3) You should still look at Bean's overlay generator design and driver. You'll still need the sync separator no matter what you plan to do.
2) The border is one pixel wide envelope around the character. In b/w inserted character it will be black, but in order to get a border signal I can assign it any color I need. And since border adds the third color in a pattern (in addition to the character and background). The necessity to have 3 colors leads me to the necessity of a custom font. Actually it's a propeller font with added border pattern of a distinctive color.·And I am only going to make the characters which will be used. If there are any alternative ideas of a border construction, I will highly appreciate it.
3) Definitely I am going to look at the mentioned design to get an idea of synchronization.
Thank you.
With a couple resistor value changes you can make the overlay less transparent.
Or the easy way would be to just buy one of my overlay boards [noparse];)[/noparse]
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never argue with an idiot.· They'll drag you down to their level then beat you with experience.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
I've been thinking since we last spoke, what is the switching speed of your video switcher? If it is a fraction of the pixel width, you may be able to use a very fast analog comparator to detect when the Propeller is sending out non-black and switch based solely off of the pixel data of the Propeller alleviating the need for a custom font with borders.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
In either case, there's going to be more to it than just switching a 75-ohm video signal between sources. Both signals have to reference a common sync level, which means the incoming signal has to be DC-restored before it can be messed with. Switching is best performed at high impedance, so fast, cheap analog multiplexers (like the 74HC4053) can be used, after which a simple transistor current-gain stage can be used to restore the 75-ohm impedance of the newly-combined signal.
An alternative would be to insert closed-captioning data, which can be programmed to yield outlined text at the receiving end. But the hardware would be the same: sync separator, DC-restorer, multiplexer, and amplifier.
-Phil
I wish it would be that easy
But·my project is for a pro courtroom videorecording systems,·so:
-·text (pixel) based font is requested - it looks a lot better, especially in a small size.
··It will be used with 30x13 characters screen, interlaced.
- my analog engineer will kill me·for any non-standard video or floating white/black levels. That is·why we use·character keying instead of·
· superimposing. It's still possible to get away with superimpose, but will require quite a few extra components.
- it shoud be SPI interfaced (not a big deal, I think).
- and quite a few other small things
I am trying to figure out how you generate black and white signal on video output. Still there...
Thank you,
Gennady
OK, seems like I confused myself and everybody·with terms.
Since overlay can be either superimposed (mix of input video and character video levels·- Hitt's solution)·or keyed (switched between input video and characters by analog switches).
We use keying. Of coarse·all the analog·requirements (sync levels, DC-restore etc.) should be followed, but I leave it to our analog ingeneer - he is great with this staff. My problem·is to give him signals for switching.
We are using on-screen-display·ICs in our systems for last 17 years. Some·have video out (easiest), some rgb (easy to program colors and use for switching). Unfortunately, almost all OSD ICs are obsolete.·NEC still makes those we use, but don't supply to US. DSP based solution can be nice, but long ang more expensive.
That's why I am trying to use Propeller. I spent a week·on spin and asm, feel less·
Thank you,
Gennady
sorry,·I don't really understand how I can generate a border (one pixel envelope around the character) this way, if it is not present in a standard font? May be I miss something, please clarify..
I thought of using analog comparators for separating of character and border signals from the custom font.·If I will not be able to separate black/white logic on different pins, this can be a possible solution.
But again, assotiated delays may compromize the video quality, and requirements are quite strict.
I also thought about a custom 'border only' 2 color font. It will need to run in a·cog, separate from the character running cog. The two should be both synched to an external video.·But I am not sure they·can run in·so strict synch. Also the necessity to update 2 screen buffers instead of one can be pain and significantly slow it down. In my case osd responce should be quite fast (following microphone tallies changes).
Gennady
Since custom font is just an array of constant longs, is it possible to put it in CON instead of VAR ?
Is it possible to assign it to a particular address ? I though it may speed up printing of characters to the screen buffer.
Also since I don't use a standard character map, I'll need to relate incoming ASCII to the character number in a custom font through the lookup table. So the above question (locating in CON) also applies to this lookup table.
Gennady
If all you need to do is provide the logic-level signals, it gets a lot easier — at least in theory. What you need is an object like TV_text, but one that latches onto an external sync instead of providing its own, and outputs two-bit (enable and intensity) data for each pixel position. The enable signal keys the "inserter" and will be on if the pixel position, or one of its eight nearest neighbors, is a character pixel; the intensity signal, only if the pixel position itself is a character pixel. This will give you a one-pixel outline around each character. This can be done using the internal font, but it will entail some heavy lifting in the assembly language department. Nonetheless, it's completely within the Propeller's capabilities. The hard part will be the routine that assembles each line from the internal font data and does the "nearest-neighbor" computations on the fly. It may take two cogs: one to assemble a line of pixels, another to output it.
-Phil
That is why I thought about 4 color custom font with outline, assigning different colors to outline and characters. But here comes the problem of deriving of logic signals for different colors. BTW, probably it still should be possible to·modify the tv_text the way that different pins will output logic signals for specific colors. And it may be even easier then in your great·solution.
Thanks for·the idea, I already see a smoke coming out of my head·
Gennady
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
if I understand your idea right, the pseudo driver will give us a shadow (we probably·can get either left or right shadow depending on a·delay between driver outputs). Still don't see how it will create a border AROUND the character.
I am trying to break my head over original Phil's idea (I dreamed pixels and bits last night - what a nightmare !).
The possible way I see to use it is as follows:
1. Have·independent cog developing one row of original characters from the screen buffer. Development should occur·while the previous row is
·· displayed or during vertical blanking interval for the first row.··This will give us roughly 64uS x 16 lines ~ 1mS to develop one row of characters.
·· (signal is interlaced).
2. The 'border driver' does the following tasks:
···- reads the monochrome character from ROM font based on address·of a character in a screen buffer.
·· - has 3 16-bit variables: tile_previous (originally 0), tile_current (current line of 1-bit pixels from a character), tile_next (next line of 1-bit pixels
···· from a character)
···· Has a row_buffer of 32 characters·x 16 longs (signal is interlaced)·= 512 longs
·· -·checks each Bit (0..15) in a tile_current·as:
······· - if Bit is 1 (character)
············ shift into the row_buffer[noparse][[/noparse]column number][noparse][[/noparse]tile_current number] %11 (character·color)
······· - else if Bit is·0 -
············ if ((tile_previous1) | tile_next | (tile_previous << 1) | (tile_previous >> 1) | (tile_next << 1) | (tile_next >> 1)) &·(1 << Bit)
··············· border - one of the neighbouring pixels is 1 - shift into the row_buffer[noparse][[/noparse]column number][noparse][[/noparse]tile_current number] %01 (border·color)
······· - else
··········· shift into the row_buffer[noparse][[/noparse]column number][noparse][[/noparse]tile_current number] %00 (background color)
· - reads the next tile and reassignes tile_ variables
3.·TV driver is assigned to read characters from a row buffer instead of screen buffer.
This way (if I am not wrong somewhere) we effectively convert monochrome (2 color) character to 4 color character with different colors for a character, border and background.
Since we can also set some pin to indicate active video (when characters are displayed), correct choice of colors may give us logic levels for switching.
We need ·512 longs buffer for·converted characters, but it's a lot less then custom font.
So the questions are:
-·are there any significant flows in the above approach·?
- will a 'border·driver' be able to do a row conversion in 1 mS ?
Will highly appreciate any input !
Gennady
···· ···
· Yes that is a great idea. Simple and elegant.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never argue with an idiot.· They'll drag you down to their level then beat you with experience.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
Seems to me the simplest way of doing bordered text is to use a screen buffer, and set the background to a colour that you are using for switching (green or blue is traditional for TV). Then draw the string you want 8 times in black, offset 1 pixel to North, NW, E, SE, S, SW, W, NW. Then finally draw the text in white in the centre.
So rather than using the border which requires special 4 color characters and is a memory hog, create a simple keying signal, when that bit is high the video switcher chooses the Propeller as the source to output, when the bit is low the video switcher chooses the original signal. Now if the video switcher takes less than 6.25 ns to switch sources, the keying signal is in perfect synchronization with the video output of the Propeller, if the video switcher takes between 6.25 to 18.75 ns to switch sources, the keying signal preceeds the video signal by 1 clock cycles, and so forth depending on how long the video switcher takes to switch sources.
The keying driver is actually very simple to create, it is another cog running the TV_Text assembly driver, pointing to the same buffer as the real video driver. The bank of pins it outputs to would be a different set than the real video driver (it needs to be it's own unique signal) BUT, the only pin set to output is the highest bit of the group. The colors are set so that bit is set 1 or 0 based on the information in the screen buffer. The TV_Text should contain both of these drivers and both drivers should enter a waitcnt upon startup where they begin execution in sychronization by waiting on the counter value, if the keying driver signal needs to preceed the video signal, it would do a waitcnt on the counter value the video driver is minus how many clock cycles it needs to preceed to provide the video switcher enough time to switch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 7/8/2007 6:51:46 PM GMT
To handle the horizontal neighbors, we can take advantage of the fact that all the normal ASCII characters in the internal font have at least one blank pixel on each side. This means we can load each character tile and OR it with itself shifted left, then shifted right, without character pixels getting shifted out. This means that we don't have to consider neighboring tiles in the horizontal neighbor calculations — only the tile corresponding to a single character.
I've modified TV.spin to see if this would work, and there's just enough time to do the shifting at 40 characters/line (so there would be plenty at 30 characters/line). Here's the original code from TV.spin that outputs the pixels:
:tile rdword tile,screen 'read tile or tile,line 'set pointer bits into tile rol tile,#6 'read tile pixels rdlong pixels,tile '(2 instructions between reads) shr tile,#10+6 'set tile colors movs :color,tile add screen,#2 'point to next tile mov tile,phaseflip :color xor tile,colortable waitvid tile,pixels 'pass colors and pixels to video djnz x,#:tile 'another tile?And here's the new code:
:tile rdword tile,screen 'read tile or tile,line 'set pointer bits into tile rol tile,#6 'read tile pixels into shift register rdlong shift,tile '(2 instructions between reads) mov pixels,shift 'Copy shift register to pixels register. shr shift,#2 'Shift righthand neighbors into center positions. or pixels,shift 'Accumulate in pixels register. shl shift,#4 'Shift lefthand neighbors into center positions. or pixels,shift 'Acuumulate those as well. shr tile,#10+6 'set tile colors movs :color,tile add screen,#2 'point to next tile mov tile,phaseflip :color xor tile,colortable waitvid tile,pixels 'pass colors and pixels to video djnz x,#:tile 'another tile? ... shift res 1I saved the modified file as "TV_wide.spin" and ran the TV_Text_Demo with TV_wide.spin substituted for TV.spin in TV_text.spin. The characters are noticeably fatter in the horizontal direction.
The fourth cog just treats the character pixels normally without shifting and outputs to the black/white pin. One thing to note here is that the timing for all four cogs, relative to the horizontal sync, is the same. But this does not necessarily mean that each cog can take its timing from the horizontal sync input pin. This depends on whether the Propeller synchronizes its inputs internally, so that all the cogs see each input change on the same internal clock edge. Paul or Chip would have to answer that one. If not, a fifth cog would have to be devoted to synchronizing the horizontal sync input by recording the value of the cnt register when it changes. The video cogs would then use this value, plus a fixed offset, to begin outputting pixel data. (Update: Actually one of the video cogs could do this, as a master timer, with the other video cogs slaving off of it.)
-Phil
P.S. Paul, I just read your post after composing mine. Are you sure the keying output and black/white output have to use different banks? It seems to me they could use separate pins in the same bank, so long as each enabled only a single pin in that bank as an output.
Post Edited (Phil Pilgrim (PhiPi)) : 7/8/2007 7:32:13 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
-Phil
To·get it working, I needed to be able to display custom 4-color font with a tv text driver.
With Paul's kind assistance it's accomplished.
Now to the current state of affairs.
The idea consists of 2 parts.
1. tv text driver should be modified to·display row of characters from a prebuilt buffer, which contains 4-color characters
··· with separate colors for a character, border and background.
···Two of these buffers exist, which are displayed on alternate basis.
2. Buffers are prepared by a font converter, residing in a separate cog.
··· When one buffer is displayed, the other one is being prepared by the converter.
·· Converter operates by converting a row of standard (built-in Parallax font) characters, pointed to by a screen buffer,
·· to a row of 32 bit 4-colors characters.
·· Since signal is interlaced, only odd or even lines of a bitmaps are developed in each field.
·· I implemented only one buffer now for test purposes.
·· I also tested an idea (probably, it was mentioned somewhere, but I did'n see it) to use an unused output pin as a flag for another cog.
·· In my case the TV driver should inform a converter to start developing the next buffer, when the current one is displayed.
·· It works, and it's very convenient.
·· Now for the fun part.
···Coversion of 2-color character to 4-color with border is based loosely on Phil Pilgrim's idea of comparing a pixel with·8 adjustent pixels.
·· I have to admit, it was pain, especially since this is my first encounter with propeller,·spin and propeller assembly.
·· The worst part was - how to convert fast a 16 bit 1-color·line into 32 bit·(insert 0's between bits of an original word).
·· Until one morning after another 'bits and pixels' nightmare I realized that propeller has already done it for me - by interleaving characters.
·· The rest was painful due to debugging, but a lot easier.
So now to the challenge.·Since the display of a row of characters in interlaced video takes 64 uS x 16 lines = 1024 uS, the conversion should not··take longer than that. Currently the scope shows (I used a pin to show srt/finish of conversion) 980 uS.
It should be fine, but I don't like to be that close.
So if somebody would take a chance to look at the attached code and see if·the coversion routine can be further optimized for speed - it would be great.
All the explanations I could come up with are in files as documentation and comments.
The serial port is just to check if the buffer is filled right -·and it shows only lines for the first field.
And if anybody took a look at this - what do you think of an idea and implementation in general ?
Gennady
I'm looking at trying to overlay full color text over a video input. I don't know if this can be done with the Prop, can it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
----
The more I know, the more I know I don't know.· Is this what they call Wisdom?