Question on transparency with the OSD layers on the DM365

DThomas said:

I'm trying to understand the capabilities of the OSD layers on the DM365.  As I understand it, I can use pixel level alpha blending with only one of the layers at a time.  Does the same restriction apply to transparency?

The pixel level alpha blending I believe you are referring to is using OSD1 as an atrribute window described in section 4.4.4.8 of SPRUFG9c. This only works for one layer (OSD0) because you have cannibalized the other layer (OSD1) to hold the array of alpha values. This does not apply to the transparency settings which use particular OSD pixel values to mark pixels as transparent.

DThomas said:

Can I set up the hardware so the transparent regions of OSD1 show the OSD0 layer?  Is that even possible?  Is there a different way to do what I'm asking?

My impression is that if you use the transparency settings described in section 4.4.4.3 of SPRUFG9c, that you should see through OSD1 to show OSD0 underneath based on the layering priorities of the OSD. Though there is not an explicit description of what happens when you have the two OSDs on top of each other when using this mode, it would make the most sense to see OSD0 underneath, if all you need are various regions of your OSD layers to be 'clear' than this seems to be the way to go.

As noted above however, this limits you to one type of alpha value for each entire OSD, the each pixel can either be transparent or solid, but but there is only one level of that transparency.

Bernie Thompson said:

As noted above however, this limits you to one type of alpha value for each entire OSD, the each pixel can either be transparent or solid, but but there is only one level of that transparency.

That would be perfectly fine.

Bernie Thompson said:

My impression is that if you use the transparency settings described in section 4.4.4.3 of SPRUFG9c, that you should see through OSD1 to show OSD0 underneath based on the layering priorities of the OSD. Though there is not an explicit description of what happens when you have the two OSDs on top of each other when using this mode, it would make the most sense to see OSD0 underneath, if all you need are various regions of your OSD layers to be 'clear' than this seems to be the way to go.

I'm trying use the settings described in that section, but it doesn't seem to be working that way.  Transparent sections in OSD1 are showing the video and not the underlying OSD0 layer.  I fear that this sentence from section 4.4.4.3 of SPRUFG9c is very literal:  "If transparency is enabled, any pixel on the bitmap display that has a value equal to that of the transparent value for that window as defined in TRANSPBMPIDX.BMPn will be transparent (only partially transparent) and allow the underlying video pixel to be displayed based on the blending factor."

So, is there other documentation that explicitly describes what happens when two OSD layers are on top of each other with transparency?

For reference, I'm using the following settings:

OSD_OSDWIN0MD = 0x00002005

OSD_OSDWIN1MD = 0x00002005

OSD_TRANSPVALL = 0

OSD_TRANSPVALU = 0

I am then filling the OSD1 buffer with 0.  The OSD0 layer contains a bitmap with it's own transparency layers.

DThomas said:

So, is there other documentation that explicitly describes what happens when two OSD layers are on top of each other with transparency?

It appears that there is not, at least not any public documentation that would show this, so I will try to explain my findings here until the VPBE manual can be updated. I did some digging into some internal documentation regarding the OSD, and it seems that OSD to OSD blending is not supported, in other words if OSD0 and OSD1 are both covering the same region than only OSD1 (the higher priority window) is passed into the blending process, so it seems what you are getting is expected and the sentence you quote is literal.

You can think if it as having just one 'blending unit' taking two inputs which can intelligently select pixels and average them together, or select individual pixels from just one or the other (a form of averaging). The inputs fed into this 'blending unit' are the OSD and VID data, which have already taken into account the window priorities between each other, which prevents you from seeing the OSD0 under the OSD1. To try to draw the basic flow in ASCII:

OSD1   \
                  ---> OSD window priority --->
OSD0   /                                                      \
                                                                       ---> Actual Pixel Level Blending ---> Display
VID1    \                                                      /
                  ---> VID window priority --->
VID0    /

Why this is not shown clearly in the VPBE manual I am not sure (or maybe I am just missing it), I will file a bug against the document to have this clarified in a future revision, at least a note to section 4.4.4.3 that says explicitly OSD1 to OSD0 blending is not supported like is said in section 4.4.3 for the VID windows.

Thanks for the chart!  Based on that information, it does not sound like I can blend three layers.  Back to the drawing board.

As a side topic, what is the input to the video encoder (i.e. let's say I want to save a mpeg file)?  Does the video encoder get the image that is going to the LCD or can you select which windows it uses for input?  Could you setup the system so the LCD receives VID0, OSD0, and OSD1 while the encoder receives just VID0 and OSD0?  If there is a high level summary on how this works somewhere, please let me know.

DThomas said:

As a side topic, what is the input to the video encoder (i.e. let's say I want to save a mpeg file)?

The video encoder block (h.264, MPEG4 codecs) reads directly from memory, it is leveraged through the provided TI codecs which you basically pass a pointer to a frame buffer to be encoded in your software (you do not work with the hardware accelerator directly).

DThomas said:

Does the video encoder get the image that is going to the LCD or can you select which windows it uses for input?

The codecs are entirely independent of the VBPE and OSD, they read directly out of memory, so you do not really pick a window, but you can send the same frame buffer in DDR to both the codec and the VPBE, they will both just read out of the same place.

DThomas said:

Could you setup the system so the LCD receives VID0, OSD0, and OSD1 while the encoder receives just VID0 and OSD0?

No, for better or worse, the OSD blended output is only available at the display pins on the device, it cannot be written back to memory (unless you piped it into another device, or looped your VPBE to your VPFE). This being said, there is no easy (or typically practical) way of getting the OSD blended output into a h.264/MPEG4 compressed video stream.

I hope this answers your questions, I don't have a good high level summary for this off hand, but if you have any more confusion on it, please let me know, I may be able to come up with a more complete block diagram which we can discuss.

Hi DThomas,

I'm curious; did you ever find a solution to your problem?  I am trying to achieve something similar; video blended with graphics, with a transparent menu on top of both.

The closest I've been able to get so far is to us transparent windows in Qt, but it does not quite give the same final effect.

Thanks!

Marlon

I did not find a hardware solution.  I blended two layers in software and then assigned the blended layer to be an OSD layer.

Ok, thanks for the response. I may have to do something similar..

Marlon