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
Make sure property names passed to g_object_notify() are in the canonical form
(ie. "last-message" not "last_message"), so that g_param_spec_pool_lookup()
doesn't have to do strdup/canonicalize/free for every single notify call.
This only applies when building against older GLib versions (< 2.26).
Use more efficient g_object_notify_by_pspec() if we're compiling against
GLib >= 2.26, and also remove work-around for g_object_notify() thread-
safety issues with older GLib versions if it's not needed any more.
Use more efficient g_object_notify_by_pspec() if we're compiling against
GLib >= 2.26, and also remove work-around for g_object_notify() thread-
safety issues with older GLib versions if it's not needed any more.
Instead return after every iteration, which makes sure that the
stream lock is released for a short time after every iteration,
task state changes are checked, etc and this allows the task
to be stopped properly.
- 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.
