... which is upon receiving new data with different PTS spec-wise,
or optionally upon each packet of subtitle data if desired by property.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=669310
Conflicts:
gst/dvbsuboverlay/gstdvbsuboverlay.c
The check for when to not memset was checking on an undeterministic 'bits' variable value,
which is only meant to be used inside the loop earlier when it is supposed to check if
clut_index is 1 together with non_mod set, as per spec:
"non_modifying_colour_flag: If set to '1' this indicates that the CLUT entry value '1'
is a non modifying colour. When the non modifying colour is assigned to an object pixel,
then the pixel of the underlying region background or object shall not be modified. This
can be used to create "transparent holes" in objects."
https://bugzilla.gnome.org/show_bug.cgi?id=666352
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the needed Android.mk files.
Androgenizer can be found here: http://git.collabora.co.uk/?p=user/derek/androgenizer.git
The dvbsub routines were originally designed as a mini lib with a
log callback (which from the looks of it in our case would always
be called and always assemble the string even with debug output
disabled). Some of these debug statements can probably be removed
or cleaned up some more.
Display size is either transmitted in the display definition segment or
implicitly defined to 720x576. The subtitle window information also present in
the display definition segment is not yet used.
* 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
The spec has a page_time_out in the page composition segment to ensure
subtitles don't get stuck on screen for too much longer than intended,
when future page composition segments get lost on bad reception, or other
problems. Honor it in the gst plugin side.
Push incoming subtitle pages in a FIFO queue (pending_subtitles)
and dequeue the head when it's time to show it (when video running
time reaches the subtitle page running time).
Keep the subtitle page, that is supposed to be blended on top of video
currently, in a separate object variable (current_subtitle). As a
next step we can then pre-render current_subtitle to a better to blend
format.
Eases holding onto the information in gst plugins side queue of
DVBSubtitles, so we won't need to create yet another temporary struct
to keep the pts and page_time_out too.
And this really logically belongs at the toplevel information set anyway
and in that struct...
We want to allow queueing of raw region image data in the gst plugin side,
and keep the data around until we pop the item from the queue. So make
the callback handler responsible for memory cleanup, if one is installed.
Abuse libdvbsub PTS tracking to just store our running time in it, to get
it back in the callbacks. As GStreamer does its own PTS handling behind our
back (especially for video), we should just sync with video per running time,
not try to do it with PTS, which doesn't seem well accessible for video chain.
We can later relabel dvb-sub.c pts naming convention if wanted, it's just
passing along guint64 values, which GstClockTime fortunately is too.
The current idea is to collect the regions returned by the callback into
a FIFO buffer and pop and pre-render the top one into a separate
quick-to-blend cached format, which is then appropriately blended in the
video chain until the next one on top of the stack reaches the video chains
running time (or the fallback timer hits).
