Remove tee and output-selector and just link the source
pad to the outputs we want as needed.
The way we need to prioritize caps negotiation and allocation
queries depending on the mode enabled is too custom to be
handled using tee and output-selector.
This provides more flexibility and doesn't get in the way of proper
handling of negotiation and allocation queries.
If the video source happens to allow max-zoom to be greater than our maximum hard coded
value of 10 then the user cannot set anything greater than our maximum specified in the
param spec. We have to update our param spec to prevent glib from capping the value
https://bugzilla.gnome.org/show_bug.cgi?id=745740
To avoid useless renegotiation of the pipe we can check for
negotiated caps on src_filter and compare it with requested
filter. If the caps intersect, avoid restart.
Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
https://bugzilla.gnome.org/show_bug.cgi?id=672610
The image capture mutex and the pad object lock would cause a race
if the pad query was made right when the image probe was running.
The image probe needs the capture mutex and the querying would need
the pad object lock.
It might be racy with the image probe thread as it uses the capture
mutex just like the start-capture handler from camerabin. The
start-capture would be waiting for the source's streaming thread
to stop to be able to set the source state to ready while the
probe would be blocked waiting to acquire the capture mutex.
It causes a deadlock.
There are unnecessary definitions for disabling deprecation warnings.
Since GLIB_DISABLE_DEPRECATION_WARNINGS is not needed anymore in these files,
removing the same.
https://bugzilla.gnome.org/show_bug.cgi?id=737559
They are kept until the probes are removed but they will never be
removed as the refcount of the element won't get to 0 because the
probes own references (cyclic refs). As the probes should only be
running as long as the element is running there is no need to
secure a ref for them.
Removes 3 leaked refs of wrappercamerabinsrc
The notify signal is triggered when caps is changed. But instead of
proxying the fixed caps, we query for the caps. Hence, when we go to
READY state, we endup setting template caps on the proxied caps
filter instead of NULL, which leads to negoitation failure. Correctly
proxy NULL caps if this is the new caps. Fixes not negotiated error
when running in cheese. Also fix a leak of caps string in one of the
trace.
https://bugzilla.gnome.org/show_bug.cgi?id=732741
In order to be able to change the caps on multiple capsfilters the
source element needs to be stopped, otherwise it will get a few
reconfigure events and might try to renegotiate while the bin
is still transitioning its caps, leading to a not-negotiated failure
and the image capture won't happen because the source will be
unusable.
The solution is to keep the source in paused while the caps are being
changed in the bin, and then bring the element back to playing once
it is done. Unfortunately this increases the image capture latency,
but it should always work.
A possible improvement to reduce the latency is to add another signal
to be called before 'start-capture': 'prepare-capture'. At this step
the camera source should set all caps it needs and get the source
ready for doing the capture as soon as 'start-capture' is called.
This can be done on a future commit
Force filesink to null before posting video-done to make sure the
file was closed.
Had to do it from a separate thread to avoid calling state_change from
a sync message handler.
https://bugzilla.gnome.org/show_bug.cgi?id=709373
By adding the video-source-filter during construction time, rather then
patching it in later (*), we can greatly reduce the amount of caps involved
in negotation, speeding up pipeline creation.
I wrote this while working on speeding up the startup of cheese. My cheese
has been modified to add a capsfilter, filtering for only the configured
resolution, with that cheese patch + this patch, the pipeline creation time
goes from aprox 1.1 seconds to aprox 350ms. This is with a Logitech 9000
pro camera, which supports lots of different resolutions at many different
framerates per resolution, causing a caps "explosion" if not filtered.
*) Note the code for this is left in, as it is still necessary if the
video-source-filter is changed between a stop + re-start.
https://bugzilla.gnome.org/show_bug.cgi?id=701953
check_and_replace_src() was setting self->app_vid_src to NULL, which
means that an app setting the video-source property, and then starting,
stopping and re-starting the pipeline (ie to make changes to the
video-source-filter property) would after the restart no longer have
a video-source.
This patch fixes this by making gst_camerabin_setup_default_element return a
ref to the passed in user_element, rather then returning the user_element as
is, so that that ref can be passed on to the bin, and the app_vid_src ref
stays valid.
https://bugzilla.gnome.org/show_bug.cgi?id=701915
The name was updated on the 0.10 -> 1.0 transition, but the
gst_bin_remove was still using the old name, causing an assertion
when replacing video-source-filter
https://bugzilla.gnome.org/show_bug.cgi?id=681564
Add a src pad event handler function that filters reconfigure events to
trigger the renegotiation code paths in the mode-specific start-capture
phase.
This is to work towards fixing unit tests but more work is needed.
need to pass a GstSample to the utilitary preview buffer post functions
as a GstBuffer doesn't have caps anymore. The GstSample has the GstCaps
and it is used to inform the preview's pipeline about the format of the
input, before it gets converted to the user's requested output format.
