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
