Replace videocrop ! videoscale ! capsfilter with the digitalzoom
bin that has the same pipeline internally and already updates
the capsfilter automatically when caps change, removing this code
from wrappercamerabinsrc and making it cleaner.
wrappercamerabinsrc has a videocrop element to be used for
zooming and for cropping when input caps is different when used
with the GstPhotography interface. The zooming part needs
the following elements:
capsfilter ! videocrop ! videoscale ! capsfilter
The capsfilters should always have the same caps to ensure the
zooming is done and preserves dimensions, unless when it is needed
to do more cropping due to input dimensions those caps
need to be modified accordingly to preserve the output dimensions.
This, however, makes it hard to get caps negotiation to work properly
as we need to have different caps in the capsfilters to account for
the extra cropping needed. It could be simple for fixed caps but it
gets tricky with unfixed ones.
To solve this, this patch splits the zooming and dimension reduction
cropping into 2 separate videocrop elements. The first one does
the dimension cropping, which is only needed when the GstPhotography
API is used and the source provides a caps that is different than
what is requested, while the second is dedicated to zoom crop only.
The first part of the pipeline goes from:
src ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
to
src ! videocrop ! videoconvert ! capsfilter ! videocrop ! videoscale ! capsfilter
It might add an extra overhead in the image capture as the image might need
to be cropped twice but this can be solved by enabling videocrop to use
crop metas so only the later one does the real cropping.
It also makes the code a bit simpler.
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.
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
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.
Camerabin2 allows setting a filter for image, video or viewfinder, but
not one filter for all three at the same time. I added a filter to
wrappercamerabinsrc to allow setting a global filter when using this
source.
https://bugzilla.gnome.org/show_bug.cgi?id=649822
Camerabin2 uses state changes to force the source to renegotiate its
caps to the capture formats. The state changes makes the source lose
its clock and base_time, causing it to stop timestamping the buffers.
We still need a proper way to make sources renegotiate its caps, so this
patch is a hack to make the source continue timestamping buffers even
after changing state. The patch works by getting the clock and base
time before doing the state change to NULL and setting them back
after putting it to PLAYING again. It also cares to drop the first
new segment after this state change.
Implement previewing functionality using 2 properties. A boolean
(post-previews) that indicates if previews should be posted, and a
GstCaps (preview-caps) to provide the desired preview caps.
wrappercamerabinsrc implements previewing by supplying the captured
image to a pipeline to adapt it to the required caps before posting.
Instead of linking 3 src pads from tee to the ghostpads, use 2
srcpads and add an output-selector to completely split caps
negotiation of video/image modes. I don't think there is an
use case that would require image and video pads to be used
at the same time.
