Don't get caught in an infinite loop if the source gets disconnected and also
support gracefully failing upon detecting the frame geometry has increased
(rather than segfaulting).
https://bugzilla.gnome.org/show_bug.cgi?id=635397
These callbacks may fire from any thread, hence we should only enqueue
buffers and let the streaming thread take care of the rest as soon as
the blocking encode or decode operation has finished.
At least as far as miovideosrc is concerned. Turns out that CoreVideo's
CVPixelBufferGetIOSurface is not present in Leopard's version of CoreVideo.
We solve this by making it possible for symbols to be marked as optional.
QTCaptureSession::addInput and QTCaptureSession::addOutput call
NSObject::performSelectorOnMainThread internally so they need the mainRunLoop to
run at least for a while to complete.
We need to reset the elements from the video recording branch, including
the queue and capsfilter in order to clear the eos state and activate
the pads.
This makes it possible to record multiple videos with camerabin2 in a
sequence, otherwise the source would get a unexpected return and
push EOS, stopping the whole pipeline.
Fixes capture location creation to use multifilesink location
like strings. E.g. using capture_%d instead of capture_0 to let
camerabin2 handle the %d replacing
As video recording bin's state is locked, we should always
remember of setting it to NULL when camerabin2 goes to NULL
Be more careful when using elements that might not
have been created yet
And do not set location property recursively on videorecordingbin
Adds a location property to enable applications to select
the captured files names. Locations are handled just like
multifilesink ones
Also disables -Wformat-nonliteral to allow to use non-literals
on g_strdup_printf on camerabin and generate a sequence of
locations for captures.
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.
