- 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
This is not really necessary here because everything is
initialized from gst_init() already but using G_DEFINE_TYPE()
removes some copy&paste boilerplate code.
In gst_element_get_compatible_pad(), when trying to find a compatible pad on an
element for a given pad, there's no point in checking the element's sink pads
if the pad to link is a sink pad as well, or the element's source pads if the
given pad is a source pad already, since those would never be able to link
anyway. Should speed up linking using the convenience functions a little bit,
or at least reduce debug log output.
The logging is not an atomic operation and because of the multi-threading we end
up with out-of-order log lines. Tools that present the log-file should probably
resort the lines. This change just takes the timestamp a bit closer to the
actual logging.
