[libbluray-devel] Clearing and wiping of YUV overlay

[Petri Hintukainen]

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
> libbluray-devel at videolan.org
> https://mailman.videolan.org/listinfo/libbluray-devel