Help with HDSDI Video streamer
DerekCa
Posts: 3
I'm not quite sure this can be done but I want to build a box, utilizing the propeller, which will provide a video functionality called a “streamer generator”. Hardware boxes in the past have been limited to composite video. Today everything is HDSDI [High Definition Serial Digital Interface]. A streamer generator superimposes a vertical [typically white] bar that “streams” [usually from left to right] across the video image such that when its projected on to the large screen an actor is cued when to say their line, because when the bar gets to the right hand side of the screen, the recorder goes in to record. Succinctly, I want to take an HDSDI [1920 x 1080] serial digital video signal and put this video image [a.k.a. “a streamer” ] over it. It lasts approximately 2 secs in duration i.e. it takes 2 secs to “wipe” from left to right across the screen. [I would need a mechanism, perhaps front panel switches, that would allow me to adjust the rate at which the vertical bar proceeds from left to right across the screen] , I'd also need a general purpose input that would allow it to be "fired" from either a relay closure or RS232 [Sony P2] protocol. This is a practical application that I would love to be able to apply the propeller micro controller to. Here is an example of a hardware box that is based on composite video: http://www.colinbroad.com/html/vs-1.html
Maybe it can’t be done with a propeller, but that’s what I’m trying to find out. Thank you
Maybe it can’t be done with a propeller, but that’s what I’m trying to find out. Thank you
Comments
So I'd say the Propeller isn't capable of creating the necessary signal on it's own.
If I understand the requirements correctly, you need to drag the intensity up to "full white", for a short burst of time, at a phase/delay that varies wrt the Hsync over two seconds. The props counters could be useful here.
The NRZI encoding makes it difficult if not impossible to "overlay" on top of the high speed serial stream itself. But if there are chips that de-serialize that data to some kind of parallel format, it may be possible to overlay "the bar" (lots of 1's) on that data, then re-serialize it for display.
I used to work at Anchor Bay Technologies Inc (the makers of DVDO Home Theater Video Processors), and now work at Nvidia (I cannot answer questions related to that work) - that's my background.
I am fairly positive this application isn't possible with any Parallax products - however, you may be able to use a Propeller or SX chip to control hardware/GUI when paired with an FPGA...
My recommendation for this targeted application is to use a few National Semiconductor parts: LMH0341 for receive and LMH0340 for Transmit. Then for cable conditioning, use a few more chips found in the National Broadcast parts guide. Grab the video to a set of timing counters using an FPGA - you'll need to decode the video data from the receiver for the pixels (keep in mind these may not be in simple 24-bit RGB; but rather 4:4:4, 4:2:2, or 4:2:0 subsampled component color which will have to be converted into RGB). Then using a format decoder (you'd need to look at the incoming timing to determine what format it is), you can use a simple counter to generate a starting edge of your white bar. Probably the simplest and least resource intensive way to draw the bar over active video is to use an alpha blend using a few MACs in the FPGA. Each frame of video you would advance that edge by a software controlled number, and you would adjust the thickness of the bar by using a software controlled variable that determines when the alpha blend flips off. So if for frame 1 you had your "on egde" at pixel 14, and your line thickness was 20 pixels, the "off edge" would be at pixel 34. At the end of a full progressive frame , you would add the speed value to the last "on edge" value. Simple hardware math. You would need to realize though that with interlaced video you can have a progressive frame at half of the field rate (60 field per second = 30 frames per second), and you will want some logic to hold off a bar advancement when the other half of the progressive frame is being displayed.
The actual pixel manipulation and decoding is too fast for a propeller to follow on its own:
SD video is 27MHz pixel clock by 8/10-bits (serialized that is 270x10 = 270MHz)
HD (both 1080i and 720p) is 75MHz pixel clock by 8/10-bits (serialized that is 75x10 = 750MHz)
1080p-60/50Hz are 150MHz pixel clock by 8/10-bits (serialized that is 150x10 = 1500MHz)
This is way too much data to push through a chip that can only run up to 120MHz with one instruction for 4-clocks (30MHz instructions) - to receive a pixel's data to memory and move the pixel data from memory to a transmit pin alone would already put you in a clock speed deficit on a single core at SD resolutions, and the clock speed is critical in this timing based application. However, you can use a lower speed micro processor for control with a high-speed FGPA that does the actual manipulation and decoding in essentially real-time. For instance, a 60Hz video signal causes a new frame to be drawn every 16.666miliseconds (approximately) - in microprocessor time this is an eternity!! You could have the FPGA receive and decode the video signal and house the the alpha blend hardware and frame buffer, then with a low speed (I2C or SPI) interface you can get information about the video signal to be able to set the bar speed in software. With two registers (hardware variable equivalent), you can set the "on edge" and "off edge" over I2C/SPI. While that frame is being drawn, you should have plenty of time to calculate the next position. Control of the bar would be completely through the microprocessor that way.
For the propeller, you could have one Cog receiving the incoming video information (resolution, Color space, frame rate, etc), and figuring out how to draw the line. Another Cog could be used for the physical interface (Character LCD screen, buttons and RS-232 control), and the last COG sending the register values to the FPGA for the line control in hardware.
One thing you will want to keep in mind is latency, the time that it takes for your device to pass video from input to output. At ABT, our DVDO products were pretty advanced to be able to do a lot of their processing (Scaling, deinterlacing, etc.) in less than one frame of video worth of time (i.e. less that 16mSec @ 60Hz). Especially if you are doing recording, timing is going to be critical - if the talent is required to interact with the video that is passed through the device, and audio recorded to another device that is not passed through the same time delay, you'll end up with lip-sync issues reminiscient of older kung-fu movies, where the audio keeps going long after the actor's mouth stops moving... Fortunately this is easilly managed by having the microprocessor also control the recording with a delay that matches the device's delay (but you need to plan for that!!!).
If you need to do color space conversion and color sampling conversions, I recommend a book that has it all: Video Demystified 5th edition.
Best,
-Tim
P.S. I like the avatar - DD (blue) and DTS (grey) data bursts on a film edge with two channels of analog audio (black)... Nice.
-T
I think my head just exploded. Thank you for taking the time to elucidate, very eloquently I might add, the intricacies of what is involved for this project. Being new to the propeller I better look for a less ambitious first endeavor. I'm also looking at learning more about Actel Nano A3PN125:
www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx