Video OVERLAY Using Propeller
dallgx
Posts: 2
Has anyone done any work with·the Propeller to OVERLAY a composite·video signal?
Video In ---> Propeller Circuit ---> Video Out, where:
Video In is a standard NTSC composite video signal (1v p-p)
Video Out is·identical to Video In·except graphics/text has been inserted into the picture.
The·Propeller Circuit·would·buffer the inbound signal, "lock"·to·the sync signals·of the·video signal, then key·the video into the buffered input video.
Thanks!
Video In ---> Propeller Circuit ---> Video Out, where:
Video In is a standard NTSC composite video signal (1v p-p)
Video Out is·identical to Video In·except graphics/text has been inserted into the picture.
The·Propeller Circuit·would·buffer the inbound signal, "lock"·to·the sync signals·of the·video signal, then key·the video into the buffered input video.
Thanks!
Comments
The input video is not buffered. The Propeller's video output routine syncs to the input signal and "overrides" the input when needed
to produce the overlaid text.
See: www.hittconsulting.com
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 12/30/2008 12:01:56 AM GMT
"656" is a very common parallel-video-bus format, where interlaced video data is transmitted with an 8-bit or 10-bit bus (plus one clock line) using 4:2:2 encoding (i.e. color sampled at half the luma sample rate).· The sync signal are embedded by using certain "special" bit patterns.· For a 480i or 576i signal, the pixel clock would be 27MHz, so if you had two or more cogs·doing the work, it should be do-able.
One cog would simply be the active bus manipulator, with 9 inputs and 8 outputs (the clock does not need to be passed through the cog since the clock doesn't change once the PLL locks - and we can take advantage of the fact that video by its very nature is a continuous serial stream).· The Cog would simply watch the incoming pins and write the output to the output pins (if you invert the clock from the input, and pass the inverted clock to the output this gives you an extra one half clock cycle to setup your outputs, otherwise, you could simply drive the output pins·"integer" clock periods late at the·cost of signal latency (and the added programming expense of video buffer management) - the invert can be done with a high speed single gate XOR, with one input driven by the incoming clock and the other driven by another output pin on the Prop).· Intenally for the "bus manipulator", you could have a keying block, which takes a hub long and writes the key to the next 32 pixels based on T/F tests - or you could work out a color map for fewer pixels... or alpha blend the values to the OSD (this would take several cogs, as to do a proper alpha blend, you need to do the following math: (input*Alpha/255)+(OSD*(1-(Alpha/255)))=Output where "alpha" is an 8-bit value - and this is all assuming an RGB 4:4:4 colorspace).
At least one more Cog would need to be watching the same input bus and clock pins to figure out which pixel was what and what color-sample was what, then dispatch the intended output OSD to the "bus manipulator" cog.
This type of application is why I'm really looking forward to the PropII - lots of very high-quality video processing becomes possible when the chip runs a little bit faster than 80MHz, features optimized hub access, has more RAM, and has other toys like dual-port rams, etc...· This kind of high-speed (near-)realtime overlay things·are also where CPLDs and FPGAs really start to make a lot more sense than a·standard micro-p, depite how powerfull and fancy the micro might be, because they can be pipelined and process things in parallel easier than a micro can (for example you could do a 32-bit fixed point math operation for the alpha blend with a·lower clock speed than you could with a 32-bit micro and a fixed-op [noparse][[/noparse]32-bits by the way being just enough to do a fixed point alpha with an 8-bit input and alpha variable assuming no sign bit - a trick for doing the "1-(alpha/255)" is to work out the 1/255 value to five decimal places and simply do an "alphaXOR255" to get the subtraction, then the "x alpha" becomes a more simplfied process of -alpha=alphaXOR255, frac=1/255 [noparse][[/noparse]which works out to: 0.00392 and could be represented as decimal 392], inputresult = input*(alpha*frac) and OSDresult = OSD*(-alpha*frac), then output=inputresult+OSDresult).· You can see than even with fixed point math, it's several steps - so a·micro-p would have trouble keeping up with the incoming data-rate.
With a slave FPGA, you could·reduce the pin-count·from the micro to only a simple SPI/LVDS interface (clock/data) for a standard text overlay, our you could widen the bus for full speed video (clock/data1/data2/data3 for 18-bit RGB or clock/data1/data2/data3/data4 for 24-bit RGB - still just 4 or 5 pins out of the micro)
-Tim
Post Edited (GreyBox Tim) : 12/29/2008 10:16:13 PM GMT
Yet again Parallax (and the great Parallax customer base) comes through for me. I am thinking a mix of the various technologies presented here will get me an inexpensive system that meets the needs of my application. We are going to use the native composite video output mode switchable to the overlay mode to give us the best of both worlds.
-David
https://www.parallax.com/product/28327
Although the Backpack is not currently in production, its schematic and principles of operation are included in the docs, and you're free to duplicate the essential elements of the circuit.
-Phil
BTW, this is not a new module. It was in production for years but is currently out of production. This is a situation I hope to remedy eventually, possibly with an updated version.
-Phil
The particulars where in my comment. (The downloads)