The flacdec API calls the write callback when performing a seek. We cannot yet
push out a buffer at that time so we must keep it and push it out later.
Flush out the upstream part of the pipeline when doing a seek.
Fixes#574275.
Use GstPoll to wait for the fd of the video device to become readable before
trying to capture a frame. This speeds up stopping v4l2src a lot as it no
longer has to wait for the next frame, especially when capturing with low
framerates or when the video device just never generates a frame (which seems a
common issue for uvcvideo devices)
Fixes bug #563574.
Non-ok flow returns may happen for a variety of perfectly legitimate and expected reasons
(temporarily not linked, seeking, pipeline shutdown), so we really shouldn't spew ERROR
debug messages to stderr in those cases. Fixes#570781. (Seems like someone already took
care of some of these.)
Standard pull mode loop based SEEK handling fails in push mode,
so convert the SEEK event appropriately and dispatch to upstream.
Also cater for NEWSEGMENT event handling, and properly inform
downstream and application of SEEKABLE capabilities, depending
on scheduling mode and upstream.
Generate win32/common/config.h-new directly from config.h.in,
using shell variables in configure and some hard-coded information.
Change top-level makefile so that 'make win32-update' copies the
generated file to win32/common/config.h, which we keep in source
control. It's kept in source control so that the git tree is
buildable from VS.
This change is similar to the one recently applied to GStreamer
and gst-plugins-good. The previous config.h file in -good was in
pretty bad shape, so unlike core and base, I didn't attempt to
leave it strictly the same, but fixed it as necessary. Needs
testing I cannot do myself.
Previously the sockaddr length used for recvfrom() was calculated as
sizeof (struct sockaddr). However, this is too little to hold an IPv6
address, so the full size of the gst_sockaddr union should be used
instead.
MS RTSP spec states that the UDP port pair used in subsequent SETUP
requests for various streams must be identical (since there will actually
be only 1 stream of muxed asf packets). Following traditional specs and
using different port pairs in the SETUPs for separate streams will result
in all but the first one failing and only one stream being streamed.
So, in appropriate circumstances, retry UDP SETUP using previously used
port pair. Fixes#552650.
