Keep vidbin state locked to avoid it going to playing without
being used and leaving an empty file created.
Check the docs on the code for details on the handling.
Adds property that informs if v4l2camerasrc is available
for starting a new capture.
It is useful for applications to know (via deep-notify) when the
property changes and a new capture is possible. Note, however, that
starting a new capture from the notify callback will cause a deadlock.
Removes the old logic for v4l2camerasrc that used the mode
property switching to start/stop captures to make it identical
to camerabin2 behavior and to allow the future addition of
pausing a video recording.
This also removes the MODE_PREVIEW as it became useless.
Implements video capture on v4l2camerasrc by using the mode property,
when mode is set to video, the pad probe pushes a new segment
and starts pushing buffers on the pad, when it the property is
sent back to preview, the pad probe pushes an EOS and stops
pushing buffers.
This is controlled by a Recording State variable, that is protected
by the GST_OBJECT_LOCK. I don't think locking for every buffer is
nice, so we could find an alternative lockless way here.
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
