use-mmap functionality has been removed in 0.11 and doesn't really
have any performance advantages in most cases anyway. Deprecate
"sequential" property to hint sequential access in mmap mode and
make it non-functional. Chances are no one was using this ever
anyway, or inappropriately.
Remove madvise() calls. We would need to do extensive configure
checks to handle these properly on different systems, and it
doesn't seem worth adding that for code that's already removed
in 0.11 or questionable anyway (like madvise DONTNEED right
before munmap).
https://bugzilla.gnome.org/show_bug.cgi?id=667292
When we don't have the requested data in the ringbuffer and we move our read
pointer to the requested position, signal the delete cond to inform the writer
that we changed the current fill level. If we don't, the writer might stay
blocked and we might wait forever.
When we don't have enough bytes in the ringbuffer to satisfy the current
request, first update the current read position before waiting. If we don't do
that, the ringbuffer might appear full and the writer will never write more
bytes to wake us up.
Only add the range when we receive a segment event on the sinkpad. The add_range
method will modify the write position, which only makes sense to do on the
sinkpad.
Set the seeking flag right before we send a seek event upstream and discard all
data untill we see a flush-stop again. We need to do this because we activate
the range that we seek to immediately after sending the seek event and it is
possible that we receive data in our chain function from before the seek
which would then be added to the wrong range resulting in data corruption.
When using the ringbuffer, handle the newsegment event like we handle it when
using the temp-file mode: create a new range for the new byte segment. The new
segment should normally already be created when we do a seek.
Doesn't actually change the default value, just makes use of the
define there is. Superficial testing with fakesink and jpegdec did
not reveal improved performance for bigger block sizes, so leave
default as it is.
A flush from the upstream element should not make buffering go to 0, the next
pull request might be inside a range that we have and then we don't need to
buffer at all. If the next pull is outside anything we have, buffering will
happen as usual anyway.
We want to forward the flush events received on the sinkpad whenever the srcpad
is activated in pushmode, which can also happen when using the RINGBUFFER or
DOWNLOAD mode and downstream failed to activate us in pull mode.
When we have EOS, read the remaining bytes in the buffer and make sure we don't
wait for more data. Also clip the output buffer to the amount of remaining
bytes.
When using the ringbuffer mode, the buffer is filled when we reached the
max_level.bytes mark or the total size of the ringbuffer, whichever is smaller.
Use a threshold variable to hold the maximum distance from the current position
for with we will wait instead of doing a seek.
When using the ringbuffer and the requested offset is not available, avoid
waiting until the complete ringbuffer is filled but instead do a seek when the
requested data is further than the threshold.
Avoid doing the seek twice in the ringbuffer case.
Use the same threshold for ringbuffer and download buffering.
We reset all the waiting streams, let them push another buffer to
see if they're now active again. This allows faster switching
between streams and prevents deadlocks if downstream does any
waiting too.
Also improve locking a bit, srcresult must be protected by the
multiqueue lock too because it's used/set from random threads.
Otherwise we might block forever because upstream (e.g. multiqueue) is waiting
for the previously active stream to return forever (which is waiting here
in inputselector) before pushing something on the newly selected stream.
When output-selector didn't receive a newsegment event it would
warn about pad being unlinked when switching pads. Making the logs
wrong and misleading.
While local filesystems will usually not cause short reads,
this may happen on seekable files on some remote filesystems.
Instead, loop till we get the requested amount of data, or
an actual EOS (ie, 0 bytes).
https://bugzilla.gnome.org/show_bug.cgi?id=665921
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We can't change most of
these in 0.10 because they're part of our API and ABI.
