Freeverb is a public domain reverb implementation. Port it as a gstreamer
element and make use of gstreamer specific features (gap aware, disconts,
controller, ...).
On the one hand, no need to collect nal if processing last one.
On the other hand, ensure AU collection processing to have sufficient
next NAL data in normal cases.
Fixes#663180.
Just proxying the downstream caps will prevent h264parse from
accepting a different stream-format than what is supported
downstream, although it could convert to a different stream-format.
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.
