From: Jason T. <ta...@ur...> - 2006-08-14 13:37:01
|
A post plugin that does scaling must also scale overlays. I'm having a bit of a problem figuring out the way to scale an overlay. If I implement add_event for the overlay manager, I find that the rle ptr is valid during OVERLAY_EVENT_SHOW events. But when I decode the rle, all I see is the overlay use for the first menu item on the DVD I'm testing with. Moving the menu selector fires OVERLAY_EVENT_MENU_BUTTON events, but for these events the rle pointer isn't valid. Does the current architecture allow for what I want (scaling the overlay)? Can someone point me in the right direction? Thanks, Jason. |
From: Michael R. <mr...@us...> - 2006-08-14 15:54:28
|
Hi, > A post plugin that does scaling must also scale overlays. I'm > having a bit of a problem figuring out the way to scale an > overlay. If I implement add_event for the overlay manager, I find > that the rle ptr is valid during OVERLAY_EVENT_SHOW events. But > when I decode the rle, all I see is the overlay use for the first > menu item on the DVD I'm testing with. Moving the menu selector > fires OVERLAY_EVENT_MENU_BUTTON events, but for these events the > rle pointer isn't valid. DVDs use one overlay per menu. When you navigate amongst the buttons, all that changes is a clipping area (where the overlay receives different coloring inside the area than outside). > Does the current architecture allow for what I want (scaling the > overlay)? Can someone point me in the right direction? It should be possible to scale both the overlay and the subsequent clipping areas. Michael |
From: Jason T. <ta...@ur...> - 2006-08-14 18:27:28
|
Hi Michael, On Mon, 2006-08-14 at 17:54 +0200, Michael Roitzsch wrote: > DVDs use one overlay per menu. When you navigate amongst the buttons, > all that changes is a clipping area (where the overlay receives > different coloring inside the area than outside). Ah, that makes sense. When I received the OVERLAY_EVENT_SHOW event, I used _x_blend_rgb32 on the overlay and examined the resulting RGBA image. When I saw only the first menu selection image, even though the image was the full frame size, I assumed something was wrong. I see now that _x_blend_rgb32 is using the hili_* fields in the overlay struct to do clipping and that indeed, the rle given with OVERLAY_EVENT_SHOW is the full overlay. My basic plan then is to convert the overlay the RGBA, use SwScaler to scale it, and convert back to RLE. Then I can intercept OVERLAY_EVENT_MENU_BUTTON and adjust the hili_* values to reflect the scaled rle. Thanks for your help, Jason. |
From: Michael R. <mr...@us...> - 2006-08-15 07:57:35
|
Hi Jason, > My basic plan then is to convert the overlay the RGBA, use SwScaler > to scale it, and convert back to RLE. Then I can intercept > OVERLAY_EVENT_MENU_BUTTON and adjust the hili_* values to reflect > the scaled rle. Sounds logical. Btw, there is a DVD SPU encoder in the DXR3 plugin directory. But I guess converting from RGBA to xine RLE overlay is much easier because the color palette is not limited to four entries. Another option would of course be to finally dump the RLE format and use RGBA for overlays throughout. Michael |
From: Jason T. <ta...@ur...> - 2006-08-15 13:53:38
|
Hi Michael, On Tue, 2006-08-15 at 09:57 +0200, Michael Roitzsch wrote: > Sounds logical. Btw, there is a DVD SPU encoder in the DXR3 plugin > directory. But I guess converting from RGBA to xine RLE overlay is > much easier because the color palette is not limited to four entries. I've run into a bit of a snag. Another one. :) So, based on my understanding of the overlays, you have a single color-indexed image (stored in RLE) and two palettes, one standard, and one for highlight. If I use a scaling algorithm that doesn't suck, such as bicubic or lanczos, after I scale the overlay image I will need to rebuild the color palette, by virtue of the fact that scaling creates new color values (antialiasing/blending edges, etc.). So in order for this to work, I need to convert the RLE to BGRA, scale, then convert BGRA back to RLE. The problem is when I convert to BGRA, I have to pick one of the palettes. If we imagine a situation where all values of overlay->trans is 0, if I pick the standard color table, I'll get a completely blank overlay. I can scale this and convert back to RLE and lose the overlay, even though if I had converted to BGRA using the highlight palette, I'd have gotten a much different picture. As an alternative, rather than converting the RLE to BGRA I could just convert it to a Y8 plane containing the color index values (instead of the colors themselves), and scale the overlay using nearest neighbor. This way the palettes don't have to change. The problem with this, of course, is that nearest neighbor looks like crap. So if I use a decent scaler, which is preferable, then we get different images depending on which palette is used. In theory, this could be a problem. In _practice_, it looks like DVD menus always use the highlight palette, and subtitles always use the standard palette. I have been looking at event->object.object_type, and I can pick the palette based on that (dvd menu vs. subtitle). So far this seems to be working, but I have a feeling there may exist a more complex DVD menu that uses both palettes for a single overlay. If this is the case, the whole approach I'm taking won't work. Can someone offer some advice? > Another option would of course be to finally dump the RLE format and > use RGBA for overlays throughout. That'd certainly be preferable. But it's a big change and I don't feel comfortable enough with the architecture yet to make it cluefully by myself. :) Cheers, Jason. |
From: Michael R. <mr...@us...> - 2006-08-16 07:58:26
|
Hi Jason, > So, based on my understanding of the overlays, you have a single > color-indexed image (stored in RLE) and two palettes, one standard, > and > one for highlight. > > If I use a scaling algorithm that doesn't suck, such as bicubic or > lanczos, after I scale the overlay image I will need to rebuild the > color palette, by virtue of the fact that scaling creates new color > values (antialiasing/blending edges, etc.). So in order for this to > work, I need to convert the RLE to BGRA, scale, then convert BGRA back > to RLE. > > The problem is when I convert to BGRA, I have to pick one of the > palettes. You could just apply the clipping and palette logic yourself and always hand complete overlays down the stream. This way the scaler will always see the entire plane. > In _practice_, it looks like DVD menus always use the highlight > palette, and subtitles always use the standard palette. Most DVDs do something like that, but I certainly know exceptions. Michael |
From: Jason T. <ta...@ur...> - 2006-08-16 12:59:12
|
On Wed, 2006-08-16 at 09:58 +0200, Michael Roitzsch wrote: > You could just apply the clipping and palette logic yourself and > always hand complete overlays down the stream. This way the scaler > will always see the entire plane. The problem with this is is that the only time I'm free to fiddle with the actual overlay plane is during OVERLAY_EVENT_SHOW events. For OVERLAY_EVENT_MENU_BUTTON events, the rle pointer is null. The highlight region for the show event will reflect the first menu item (if it's a DVD, say), but then the clipping and palette requirements will change for each subsequent menu button event, but they will always use the scaled overlay from the show event, which will have been computed with the wrong clipping and palette for this event. Or have I misunderstood you? Thanks, Jason. |
From: Michael R. <mr...@us...> - 2006-08-16 13:05:56
|
Hi Jason, >> You could just apply the clipping and palette logic yourself and >> always hand complete overlays down the stream. This way the scaler >> will always see the entire plane. > > The problem with this is is that the only time I'm free to fiddle with > the actual overlay plane is during OVERLAY_EVENT_SHOW events. For > OVERLAY_EVENT_MENU_BUTTON events, the rle pointer is null. But I think you could keep a copy of the RLE around for later use. Then, when the menu button changes, you apply the whole clipping and paletting yourself, convert it to RGBA, scale it and send it downstream. Michael |
From: Jason T. <ta...@ur...> - 2006-08-16 13:36:13
|
On Wed, 2006-08-16 at 15:05 +0200, Michael Roitzsch wrote: > But I think you could keep a copy of the RLE around for later use. > Then, when the menu button changes, you apply the whole clipping and > paletting yourself, convert it to RGBA, scale it and send it downstream. True, I could do that. And then lookup the rle based on the overlay passed to the add_event. But there doesn't seem to be any way to uniquely identify an overlay with OVERLAY_EVENT_MENU_BUTTON events. event->object.overlay->rle is null. event->object.overlay ptr changes with each event. event->object changes with each event. So I can grab and save the RLE passed to the initial show event, but then for subsequent events involving this overlay, I won't know how to lookup the RLE. I could just have a single rle_save ptr in the post plugin's internal data structure. And this might work for most cases. But for cases where there are more than one overlay at a given time, this will fail. Do you have any ideas how I can distinguish overlays given a menu button event? Thanks again, Jason. |
From: Michael R. <mr...@us...> - 2006-08-16 13:41:14
|
Hi, >> But I think you could keep a copy of the RLE around for later use. >> Then, when the menu button changes, you apply the whole clipping and >> paletting yourself, convert it to RGBA, scale it and send it >> downstream. > > True, I could do that. And then lookup the rle based on the overlay > passed to the add_event. But there doesn't seem to be any way to > uniquely identify an overlay with OVERLAY_EVENT_MENU_BUTTON events. > event->object.overlay->rle is null. event->object.overlay ptr changes > with each event. event->object changes with each event. I thought there was something like a handle (basically an ID) available somehow. > Do you have any ideas how I can distinguish overlays given a menu > button > event? I doubt that multiple overlays are widely used. At least DVDs use at most one. Michael |
From: Jason T. <ta...@ur...> - 2006-08-16 14:03:18
|
On Wed, 2006-08-16 at 15:41 +0200, Michael Roitzsch wrote: > I thought there was something like a handle (basically an ID) > available somehow. Aha yes, you're quite right. Perfect. > I doubt that multiple overlays are widely used. At least DVDs use at > most one. It's always the corner cases that complicate matters. :) Thanks, Jason. |