I was wondering how other VIP users were creating alpha channels for custom blocks that don't render into a frame buffer. I've recently discovered that the VIP Alpha Mixer treats the alpha and data channels for a given video layer as independent sources. Generating data/alpha information in parallel doesn't work if the source is streaming in real time since the two parts of the pixel have separate ready/valid handshake controls that aren't guaranteed to be in sync with each other.Is there a recommended technique for handing these situations? We have a lot of different applications for streaming data generation and rendering the data to a frame buffer first really isn't an option for us.
Hi eliljey,I think the alpha stream should be generated along with the video stream to guarantee that they are matched in packet size. You may find this example design (on Thread ID 32696 - sorry I am not able to post a hyper links before I have 5 posts) useful, which has an Alpha Source block to provide constant value alpha stream for the input video stream, and also shows some ways of providing alpha stream for different kinds of source. Hope this help, rayh
Thanks for the info. I'll check out the thread.I found a Chroma Key block in the UDX reference design. It isn't an official block but it does do alpha separation so you can send in a stream with the alpha as one of the color planes and it will strip it off. Unlike the Color Plane Sequencer, which can do the same thing, it will truncate the alpha to a different width so if you have a 10 bit system you can produce an alpha channel that is compatible with the mixer. Through Altera support I've learned that only a small buffer is required to pad the two streams and handle the disassociation from the mixer. I'm trying to get a spec on exactly how much buffering is required.
Glad to know that you have found solutions to the problem.Just one thing to note, If the alpha stream is separated from the video stream using Color Plane Sequencer, and sent to a consumer block, e.g. Alpha Mixer, a FIFO buffer (and probably Timing Adapter to convert between ready latency 1 and 0) is needed at the alpha path to avoid deadlock. The Chroma Key probably does not need this because it already has a build-in output FIFO. A depth of 8 or 16 pixels should do the job.
Hi,Have you used chroma key IP for setting the alpha value? I want to know what parameters to set in qsys and how to configure it through nios. I had tried this but i was not successful.
The Chroma Key block has a number of different modes of operation so it depends on how you're trying to use it. I've used it to create an alpha channel for a block that did not have alpha to begin with. For example, mixing video with an OSD overlay. The OSD has transparency, the video does not. The Chroma Key block creates an alpha channel for the video so they can be mixed. I believe they refer to this as "constant alpha" since the alpha value is the same for the entire frame. We don't ever change the alpha value in this case, but we could if we needed to. Is that how you're trying to use it or are you trying to peel off the alpha from the source to separate it before it gets to the mixer?
Yes i am trying to use it as alpha channel for a video for mixing it using alpha blending mixer. I want to change the transparency of this video dynamically through nios during run time. I have achieved a constant value but I do not know how to change it. Pls guide me with this info.Thanks!
The alpha value defaults to what you entered for the DEFAULT_ALPHA_VALUE parameter but can be changed by writing a new value to register 2 in the register map. This is based on version 1.0 of the documentation for this block.
Ok so i have to write my new alpha value to register 2. Thanks for the info, il try this and could you please give me the link to that document, i did not find any document on this.Thanks again!