This adds properties to use the clock time for deciding when
to drop buffers for inactive pads and a property to buffer all
not rendered buffers for the active pad to allow pad switching
without losing any buffers at all.
The linking behaviour of external variables that are not initialized
in the compilation unit where they are defined is undefined. On OS X
this causes a linking failure when statically linking GStreamer.
The proto for helper_find_suggest has a different argument than the actual
function in the same file has. This causes the Sun Studio compiler to fail.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676624
When the bin does an upward state change, try to avoid doing a downward state
change on the child and vice versa.
Add some more unit tests for this fix.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=621833
The src is the final stop for this event, and the default result is FALSE
for all sources not implementing event handling, which again will result
in a warning about latency not being able to be configured.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=667299
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
They can be used to select snapping behavior (to previous, next, or
nearest location, where relevant) when seeking.
The seeking implementation (eg, demuxer) may currently ignore some
or all of these flags.
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.
After a writer has written to its reserved write location, it can only make the
location available for reading if all of the writers with lower locations have
finished.
Fix a race where the reader would see the updated the tail pointer before the
write could write the data into the queue. Fix this by having a separate reader
tail pointer that is only incremented after the writer wrote the data.
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.
