... which could lead to a premature eos being reported downstream,
rather than a successful partial read which would result when
performed directly on e.g. basesrc.
Other than saving an immense amount of 4 bytes of memory this
prevents clang from complaining and keeps the ring buffer state
in a single variable instead of two.
If downstream is operating in pull mode, short-circuit any pulls beyond
the end of the file and return FLOW_UNEXPECTED immediately instead of
sending a seek beyond the end of the file upstream, since this might
confuse upstream elements (and/or http servers, for example). Fixes
playback of apple trailers in totem and youtube/html5 clips in
WebkitGTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=632977
- Set reading_pos correctly in _create_read ()
- Seek to data if it is further than QUEUE_MAX_BYTES (queue) -
cur_level.bytes away. This should avoid a situation where the ring
buffer is full but the data offset from which we shall read is not in
the ring buffer.
- Only update the max_reading_pos to a lower value to protect data when
necessary
- Always signal an ADD in _locked_enqueue () so that an EOS unlocks the
reader
- More useful debug output
update_buffering () needs to be called every time we write to the ring
buffer so that applications don't get stuck waiting for a 100% buffered
message while queue2 is waiting for space
_create_write () must only be called for temp file/ring buffer cases
Cached data could have been overwritten so it is now protected until
it is read. Similarly data was overread as _have_data () was always
looking for the originally requested data even if part of it had been
read already.
Use cur_level.bytes to see how much space is free in the ringbuffer.
Simplyfy the write function, avoid taking subbuffers, move waiting for free
space in one spot, use simply counter to write data of a buffer.
- make _get_range () emit the del signal once a buffer has been read
- use do {} while (); for wait code as queue is locked and no data could
have been read in the mean time so it makes no sense to check before
waiting
- make _is_filled () more robust
Current range was being updated in the thread performing seek, but as
no locks were kept for a short section, data flow could resume before
current range updated, so data for the new range would be accepted as
from the previous range.
Rather, range should be updated in serialized manner based on
newsegment event.
When in download mode and we need to provide data for an offset that we don't
have, also perform a seek to the requested location when we are EOS. The reason
why we shouldn't wait for more data is because after EOS, there simply will be
no more data and we end up waiting forever.
Fixes#620500
Maintain a separate variable to control src and sink flowreturn values so that
we can unlock the src part without shutting down the sink part.
Add flushing for upstream pull based elements that unblocks our getrange
function. This implements seeking when blocking for more data.
Add some arbitrary threshold before attempting a seek. Add a FIXME for this
because we need to find a sensible threshold based on the input rate.
When in download mode and the requested offset is too far away, attempt to do a
seek request to fetch the data.
Keep track of all downloaded parts and merge ranges when needed.
Fixes#600877
Add an option to automatically remove the temp file (TRUE by default). This
should make it possible for the application to keep the temp file by other means
than hardlinking or holding an fd open.
Fixes#607739
Cast the variable to gint to conform to the printf format used.
It is casted rather than changing the format because the
message is created with a cast to gint too.
queue2 would crash when using small buffer sizes because
it would overflow when calculating the percentage, resulting
in the buffering GstMessage not being created and trying to be
used. This patch uses a gint64 instead of a gint to do the
percentage math, making it harder to overflow.
Using the current fill level of the queue, and the average input
rate, we can determine how long it will take to finish downloading
the whole stream to the temporary file.
Fixes#600726
