I’ve been trying to come up with an high-def OSD to overlay pixels on top of a component signal. Something like VideoOverlayShield - Low Voltage Labs but with higher resolution and colored pixels support.
On Screen Display controller that takes analog RCA-like video input and overlaps graphics into it; and outputs old analog RCA-like video.
The controller must be relatively easy to program, support colors and high resolution lines/animation.
Closed-captioning encoding/decoding to support low rate data transfer (like teletext in analog TV broadcasts)
Having the possibility to output high resolutions (640x480+). Going from analog video to 1080p would be awesome.
So my ideia is to use .NET Micro Framework to overlay information over an analog video signal. Having future-proof support for high resolutions would be awesome.
The goal is to prototype this using a FEZ Panda II board, and then creating a GDI .NET MF on chip integrated solution.
So my questions are:
Can this be done?
Do I really need a special chip to receive analog video into .NET CF? Could I possibly get the video data into a .NET object, manipulate it using GDI and then outputting the bitmaps over an analog output faster than 24fps?
If I really require the video overlay chip, what are the best programming options? Im looking at many chip options: MB90092, LC74776… Is there something better? How could I program this? Creating a test board for the MB90092 would be super-complicated?
Yes it is possible.
Take a look at the following breakout board https://www.sparkfun.com/products/9168
It is based on MAX7456 (single channel, monochrome OSD). It is not color, though. This one can be easily controlled from NETMF using SPI interface.
I actually have a prototype Gadgeteer module designed using MAX7456. (Need to tweak it a little bit, before making a full post about it)
I am afraid you do need a special chip, because of the resource required. It is better to offload all that video signal generation to the dedicated chip.
To select which one to use is up to you. I would compare typical schematics, which is usually included in the datasheet, and choose the one that I am most comfortable with.
Welcome to the forum!
If you are looking to be able to handle 1080p then you will need a seriously powerfull processor on the module. 1080p is a huge amount of data (1920x1080 pixels for every frame 60 frames per second) and for is kind of input you are going to need a serial digital video source (SDI). If you go withn1080i then you could use component video in Y, Pr,Pb format.
A single RCA as you have on that shield is going to be a composite video signal and probably NTSC only although it may handle PAL.
If your OSD has any kind of movement on it you will need a GPU to render the frames in 1080p. To give you an idea most broadcast 1080p graphics systems use an NVidia quadro FX 5800 ( that does do real time 3D though)
I checked many different options and it seems that the MB90050 is the only controller that fits part of my requirements.
It also needs to be something tiny and light, so I can’t have any bulky extra processors. It also must have component in-out.
Architect, I was playing with the Sparkfun data sheet for their MAX7456 board; and trying to come up with my own test board for the MB90050. Have you ever heard of that chip? Using it would be something super difficult to do?
I’ve looked for any demo of this MB90050 but couldn’t find any. Just one guy saying that he build a test board and the text wasn’t as stable as the MAX7456.
I wonder if that’s a result of shaky current or bad input video signal from his part…
I’ve priced this chip and it’s about $2 a piece. I’ve put a purchase order forward for it, and I’m keen on building my first QFP test board using it… I have no ideia if I can actually solder it without damaging several chips… I’ll have a go using some old RAM I have laying around…
As for the MB90050 board circuit, does it look too different from the MAX7456?
At the end of the day what I want to do is to overlay pixels produced inside a .NET Micro Framework device to a component signal. So all this BASIC programming and everything else is really not my final goal.
What would be the easiest way to programaticaly display colored pixels on top of component signal? (using a decent resolution, 640x480 lets say).
The end game would look like the video you posted, but with the white pixels getting created using .NETMF a few times per second in a bitmap.
I was reading about the component video signal structure and decided to give a try generating it directly from native code.
But in order to do that, I was considering two possible limitations:
Each line in the video signal takes 64us to render. To make it happen, I’ll need a nanosecond delay to get the resolution I want. Reading about how to code a nanosecond delay in ARM, apparently I have to take into account the processor frequency.
Even if that’s possible, how can I free up the gaps in between the 10 nanoseconds for other processor tasks? Is it efficient to schedule this update task to run every 10 nanoseconds?
That’s probably true as far as Gadgeteer boards go, but there are higher-powered NETMF boards. For example, the Topaz i.MX25 has a 400 MHz ARM9 CPU. Still not going to be nearly fast enough for nanosecond response times, though. For this sort of thing you either want a packaged solution, or you need to break out your FPGA and get cracking.
I’m not planning to output video using managed code.
The plan is to draw a bitmap using managed code and then pass it on to native arm code that will output the signal out. One of the things to take into account is how to avoid locking the entire processor in a loop just for video. Is the native schedule extension method efficient for nanosecond scheduling? Most likely not…
If you remove the netmf completely, and you run on bare metal, and you ONLY generate video, written in assembly, then you will STILL need a 1GHz, or faster, processor to get 1ns resolution along with actually outputing the video signal.
Your best route would be to look at FPGA, to use a 3GHz PC and write the video code in assembly, then use a netmf board to generate the bitmap and pass it to the PC to generate the video.