Use 'mode' enum definition from gstcamerabin-enum file to avoid
conflicts between v4l2camerasrc and gstcamerabin2 modes.
For now there is a MODE_PREVIEW there that is only used on the
camerasrc, not sure if we are keeping it at the future, but for
now this works.
Adds mode property to camerabin2, allowing users to
select between video and stills capture. Also adds
start/stop capture actions to trigger and stop
capturing
Adds an bin that is responsible for encoding and saving video
streams to files.
For now it is simply a ffmpegcolorspace ! theoraenc ! oggmux !
filesink bin.
Still uncapable of recording audio.
Adds viewfinder bin element, one of the modules of camerabin2
that is responsible for displaying the video from the camera.
For now it is only a bin with ffmpegcolorspace ! videoscale !
autovideosink
This holds all newsegement and most other events till there is enough
data to set srcpad caps, so that the downstream link is properly
negotiated before data starts flowing.
https://bugzilla.gnome.org/show_bug.cgi?id=635204
This holds all newsegement and most other events till there is enough
data to set srcpad caps, so that the downstream link is properly
negotiated before data starts flowing.
https://bugzilla.gnome.org/show_bug.cgi?id=635205
* 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).
