On pe, 2015-06-12 at 22:12 +0200, Richard Hulme wrote: > Hello, > > How exactly should the BD_OVERLAY_CLEAR and BD_OVERLAY_WIPE commands be > implemented?
There's an example implementation in player_wrappers/xine/input_bluray.c > The contents of the overlay are 8-bit indexes to a palette. Each pixel > cannot do anything other than reference an entry in the palette but if > the contents of the palette can be set to anything, how can you ensure > that a pixel has been cleared? > > The palette could be scanned to find a transparent entry, but is there a > guarantee that at least one entry will be transparent? I could imagine > it's likely but not necessarily guaranteed. Palette entry 0xff is reserved for (transparent) background. And yes, this is clearly missing from API documentation. (In bitstream 0xff is commonly used in compressed images, but never present in palette) > Even if a transparent entry is found, it may not remain transparent if > the palette is updated. > > Another way would be to maintain an additional 1-bit mask but that seems > rather inefficient. > > As far as I can tell from the code, these two commands are not directly > linked to the structure of a Bluray disc, but have been created as part > of the libbluray implementation. > > I'd be very grateful for an explanation of the design considerations > behind these commands (or a pointer to any documentation). The interface was originally designed to be low level (or internal) interface for HDMV mode graphics engine. It is optimized for low memory usage and fast (software) rendering. It does not require any timers (or dedicated thread) for the graphics engine; all processing is triggered by user actions and stream reading (upper layer is responsible for synchronizing the overlay and video frames). Key feature is support for zero-copy PG pipeline (images are uncompressed and rendered when used, color space conversion and possible alpha pre-multiplication is done only once for each palette entry). Clearing the overlay is implicitly required (well, it could be closed and re-opened). Clearing a region is just an optimization to allow drawing only changed parts of the overlay plane (and, yes, it could be implemented by creating and drawing transparent image). Optimized implementation can keep a list of currently visible images and render those directly over video frame. Wiping in this case means removing corresponding image(s) from the list of images that need to be rendered over every video frame. Images are guaranteed to not overlap. It is possible to patch the library to provide only complete ARGB frames. This would simplify application side (=only one interface for overlays). But with some discs this would lead to significant increase in subtitle queue memory usage (we measured over 500 MB increase). Also not all hardware supports HW ARGB overlays, so this would lead in significant performance loss with software-rendered subtitles. Memory usage could be reduced by requesting the library to render overlay directly to displayed frame, but this does not fit well to the architecture of most media players. And we would need to support N+1 different color spaces ... This feature is missing because of implementing both interfaces is quite simple, and providing HDMV mode graphics as complete frames was never requested ... But, I still have the code to convert everything to ARGB inside libbluray if you think it would be useful feature. > Thanks in advance! > > Richard. > _______________________________________________ > libbluray-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/libbluray-devel _______________________________________________ libbluray-devel mailing list [email protected] https://mailman.videolan.org/listinfo/libbluray-devel
