dvbsuboverlay: Fix more of the blending, so it looks quite good now
authorMart Raudsepp <mart.raudsepp@collabora.co.uk>
Wed, 1 Dec 2010 07:59:14 +0000 (09:59 +0200)
committerEdward Hervey <edward.hervey@collabora.co.uk>
Wed, 8 Dec 2010 15:30:10 +0000 (16:30 +0100)
commita203ad1aab9efbf1e70fbe402c0d411114b11e68
tree142195be9e689bfda3c62ed84b2fabb1f1e504ce
parentefa1e9a1fec13391a41c6010dc2ef4b03c262cf9
dvbsuboverlay: Fix more of the blending, so it looks quite good now

* libdvbsub gives us alpha channel already, not transparency level, so
don't do another "alpha = 255 - alpha", this is done by libdvbsub.
* Fix alpha channel handling in interpolation - assrender had an additional
1bpp alpha bitmap as a possible mask, we don't. So don't use the palette
index array as alpha values; bug from quick code porting long ago to
changing pixel colors (assrender has a single pixel color for whole
regions or something, unlike dvbsub, which has indexed colors).
* Don't forget to reassign our YUV and other local pixel color variables
after shifting to work on the bottom part of a 2x2 subsample block, or
it's obviously very blocky.

Remaining issues in blending:

* Should probably be interpolating or doing something else useful with the
resulting U and V channels, so that most of the source pixel UV values would
actually be actually cared about, except for just one out of possibly four.

* Don't convert AYUV to ARGB in libdvbsub, and then back from ARGB to AYUV in
dvbsuboverlay for no reason

* Re-factor the whole thing to something more like textoverlay blending
* Related to that, perhaps cache the current spu in a good format for quick
blending on each frame, after which the more often called blending parts
might become more straightforward
gst/dvbsuboverlay/gstdvbsuboverlay.c