Range errors are already turned into EOS when the size is not known.
Do the same thing if the request as outside the known content size.
This can be triggered by seeking in a queue2:
- Ensure that the range containing the end of the file is available.
- Seek into this range from a different range.
- queue2 creates a seek event with start=<file-size>
- this results in a "Requested Range Not Satisfiable" error
Fixes#452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385>
Previously imagefreeze would always operate as non-live element and
output frames as fast as possible according to the configured segment
(via SEEK events) and the negotiated framerate from start to stop or the
other way around.
With the new live mode (enabled via the is-live property) it would only
output frames in PLAYING. Frames would be output according to the
negotiated framerate unless it would be too late, in which case it would
jump ahead and skip over the requirement amount of frames.
This makes it possible to actually use imagefreeze in live pipelines
without having to manually ensure somehow that it would start outputting
at the current running time and without still risking to fall behind
without recovery.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/653>
We never run as a live element, even if upstream is live, and never
output any buffers with latency but immediately generate buffers as
fast as we can according to the negotiated framerate.
Passing the query upstream would proxy whatever mode of operation
upstream has, which has nothing to do with how we produce buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/653>
The pool orphaning function was colling internal _stop() virtual function
implementation. This is not thread safe, as a private lock inside the buffer
pool is supposed to be held. Fix this by keeping delayed _stop() and orphaning
the GstV4L2Allocator instead (REQBUFS(0)).
Then, protect the orphaned boolean with the object lock for the case a buffer
is being released after we have orphaned the buffer. That would otherwise
cause a QBUF to happen while the queue is no longer owned by the buffer pool.
This boolean is otherwise used and set from the streaming lock, or after
threads have been stopped (final cleanup).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/648>
On streamon, we need to resurrect (queue back) some buffers, as during
flushign seek we'd endup with an empty queued. We initially started with
resurrecting as many as we could without blocking, but that miss-behaved with
dynamic CREATE_BUFS, causing the pool to grow dramatically. This was limited
by the number of allocated buffers, but this still tried to resurrect too many
buffers for the first run, as activating the pool will queued buffers.
In this patch, we calculte the missing detal in the queue and only try and
resurrect that amount of buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/651>
