Alpha blending mixer's alpha blending port.

[Altera_Forum]

hi, 

 I'm using the alpha blending mixer inorder to mix two video streams, one is 800x600(background layer) while the other is 640x480(overlay). In addition I'w activated the alpha blending port inorder to "draw" shapes on the 640x480 layer. The mixing of the layer seem to be working and also I'm able to "draw" shapes in most parts of the 640x480 stream.   The problem is that at certain columns (column 3 to 5 and columns 296 to 299) in the 640x480 it doesnt seem that the alpha value provided to the alpha channel are taking effect on the output screen. When providing alpha values in columns 6 and 300 the alpha values are "smeard" on to a couple of the following columns on the output screen. Another strange thing is that if I for instance start placing the alpha value in column 2 and stop in colum 7, then all the columns in between are getting alpha values(I'm only using 255 or 0 for the 8 bit alpha values).   I'm using signaltap to see what transactions are taking place, and I'we noticed that the source "ready" signal of the 640x480 stream goes low at columns 6 and 300, so this might have something to do with the issue. Is it so that the alpha channel "shuts down" at around the time the source "ready" signal goes low ? If so, how can I correclty provide alpha values for the affected columns ?    Would really appreciate if someone could give me some direction/guidance here

[Altera_Forum]

Hi, 

 I would suggest checking that you implemented the Avalon-ST specs (and Avalon-ST Video specs) correctly for all four inputs (din_* and alpha_*). There are independent ready signals for the sources and for the alpha sources and there is no guarantee that the inputs will be ready simultaneously. You should also avoid making any assumptions on their behaviour. For instance it could be possible, in theory, that the alpha channel is not ready until you have fed a dozen of pixels into the corresponding din input, It is easy to create a deadlock if trying to feed all inputs from a single source module.  One of the ready signal probably goes low at column 6 because there is a small FIFO at each input of the core and it can contain about that many samples. This is expected and the core will go ready again once it is actually processing the data it buffered.  One of the four ready signals going down at column 300 seems a bit unusual if you have valid data available on all four mixer inputs. It may be due to another core downstream applying back-pressure but this could also be the time when a spec violation has already happened.  vgs

[Altera_Forum]

hi,  

 regarding the Avalon-ST spec (see attached file), I'w placed a custom module infront of the VIP mixer module. The purpose of the custom module is to provide alpha values to the alpha blending mixer's alpha input port (only for the 640x480 stream).   The custom module receives the 800x600 stream from the VIP Frame Reader module and this steam is shifted "as is" straight through the custom module. The same goes for the 640x480 stream, which is received from an VIP Frame Buffer. Since the 800x600 stream is the background layer, it's alpha values are ignored, and all I'm actually doing is that I'm using row and column counter and providing alpha values for the 640x480 stream. Also, I'm providing the valid signal for the 640x480 alpha input port.  At the moment I'm not running into deadlocks, and I belive that the "ready" signal which is going down at column 300 is due to one of the components(not sure which one) in the 800x600 stream's chain.    Do you think that I should combine (and-ing) all 4 of the "ready" signals before providing the "valid" signal to the 640x480 alpha port ? In other words, should I stall the alpha values when any of the "ready" signals go low ? At the moment the "valid" signal is independant of the "ready" signals, I did try connecting the 640x480 source "ready" signal to it, but this distorted the video output.  At the moment my main concern is how to provide the alpha values durring the "valid" low periods

[Altera_Forum]

Hi, 

 I am not sure I understood fully how this custom module works but it would be way safer to generate the alpha stream independently and without dependencies to video_source_* and/or video_sink_*.  See the Avalon-ST spec for more details but you must not assert video_alpha_valid and send data to the core if video_alpha_ready was de-asserted the previous cycle. Do not AND the video_source_ready and the video_alpha_ready signals because you may hit one of these deadlock cases I was talking about. There is no guarantee that the two inputs will be ready together and the mixer core could wait for a few valid video pixels before it starts accepting data on the alpha channel.  When generating an alpha frame, the first sample of each frame must be a 0 and have start of packet asserted. After the image packet header is sent, you may run your two counters each cycle to generate the alpha samples you require (but you must deassert valid and freeze each time the video_alpha_ready signal is deasserted as mentioned above). The last alpha sample of the frame must come with end-of-packet asserted.  I assume you will want to do something more complex in the future and that the alpha values may be dependent on the video data pixels. Consequently, another venue to explore would be to use the color plane sequencer. You may create a custom block that converts RGB to RGBA by just tacking the alpha value to the data wire and add a fourth color channel to the stream. This can easily be done without compromising the Avalon-ST Video protocol. You can then put Altera's color plane sequencer after your block to split RGBA back into two independent streams RGB and A. You can then connect RGB to the mixer video source and alpha to the mixer alpha source. It is possible that a small Avalon-ST FIFO will be required on either of these paths (once again this is to prevent a possible deadlock situation).  vgs

[Altera_Forum]

Hi,  

 the custom module was setup so that the 640x480 streams "startofpacket" (for the active video data) was used as an reference for when to set the "valid signal on the alpha port.   Also, I have been using the "startofpacket" and the "endofpacket" of the 640x480 video source as the "startofpacket" and "endofpacket" signal for the 640x480's alpha input.   I'll try providing the "valid", "startofpacet" and the "endofpacket" completely independant of the source signals, and follow the rest of the guide lines.    Appreciate your tips for "baking" the alpha into the RGB stream, splitting it up and delivering it to the mixer      regards   LightPhase1