Reduce start-capture workload by moving the elements' state reseting to the
finishing steps of the capture. This reduces the time start-capture takes to
actually start a capture and return to its caller, improving user experience.
As the elements' state reset is now triggered from the message handling
function, it needs to spawn a new thread, changing state from the pad's
task would cause a deadlock.
Adds a new variable to keep track of the state of the video
recording in camerabin2. This allows start-capture to reject
new video recording requests when one is already ongoing. This
fixes one of check tests.
Rename the image taglists' mutex into image capture mutex and
use it also for the image capture list to prevent concurrent
access from different threads (application and capture threads).
Do not store preview location is post-previews is false, this would
mess up preview naming in case application switches between enabling
and disabling previews
Tags are currently sent from start-capture, which is run in the
application thread. For images we can delay the tags pushing to the
buffer probe and push the tags with the location event and reduce
start-capture time.
Some messages might be interesting to applications, so we can only
decrement the processing counter and send the idle notification
when those messages are posted on the pipline's bus
Generating and posting preview image always comes with a performance
penalty so set default value as false. The preview-caps property that
defines the preview image format is also NULL by default, so instead
of generating preview image of unspecified format by default explicit
action from application should be required for enabling preview image
posting feature.
Application also has to add custom code to be able
to handle preview messages on its message handling function anyway.
This is probably the cause for an occasional crash while streaming
MPEG. Blind fix after staring at the code and following logic, so
may or may not fix the issue, I cannot test.
Makes camerabin2 only signal that it is idle after all previews have
been generated, images are captured and saved, and videos have
been finished properly.
When vui->timing_info_present is 0, vui->fixed_frame_rate_flag and others
cannot be accessed since they have not been set.
It was also possible that sps->fps_{num,den} end up initialized here.
Due to the addition of an unconditional inclusion of config.h in
mjpegtool 2.0.0's stream_params.h header the autoconf test for the
mplex module failed. Hack around this in the same way we did for
mpeg2enc.
https://bugzilla.gnome.org/show_bug.cgi?id=661614
