We must wait for camerabin2's stop-capture procedures to finish before quitting
the main loop or firing off the next capture. If we get stuck waiting for
camerabin2 to become idle, this is a bug that needs fixing.
Instead of probing the videosink sinkpad for passing EOS, better
to wait for EOS from the bus.
This makes sure the filesink has already processed it and is
ready to close the file. This is used to notify applications
that camerabin2 is idle and can be shut down.
This is not implemented in any of our real sources to which wrappercamerabinsrc
might connect but this is optional and can be implemented at any time. A
limit on the software zoom level using video{crop,scale} would be arbitrary.
Use resource warning messages to notify camerabin2 that a capture
as aborted or couldn't be started, making it decrement the
processing counter and making the idle property more reliable.
Setting the audio source to null isn't needed and it could
make the EOS that is still flowing be dropped if autoaudiosrc
is used because its pads go flushing before the EOS gets pushed
from the real source.
Checks if the new received preview-caps are equal to what is
already in use, skips the preview-caps setting logic in case
new caps are same as current ones.
Adds another test that checks that the idle property works
correctly when bogus start-capture calls are made.
This fails currently, but should remind us of fixing it in
the future by defining a proper error reporting from camera
sources to camerabin2
The rationale is that it can't be properly used right now when using
it to encode mpeg2video because of the needs-to-be-rewritten properties
and format negotiation. Other encoders will negotiate in a much saner
fashion.
One such example is that when you pick mpeg2enc for mpeg2video, the
default value for the 'format' property is "Generic MPEG-1", which is
completely wrong if downstream caps are mpeg2. The whole negotiation
code needs some serious loving before this plugin can be bumped back
up to a higher rank.
gst_caps_make_writable() takes ownership of the caps passed in, but
the caller doesn't own a ref to the caps here, because GST_PAD_CAPS
doesn't return a ref. Looks like the code relied on a caps leak
elsewhere for this to work properly.
If downstream doesn't handle the newsegment event, don't error out (esp.
not without posting a proper error message on the bus), but just continue.
If there's a problem, we'll find out when we start pushing buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=644395
