Enhance default_reset_buffer() to resize the buffer to its full size if the
memory hasn't changed. This allows to reuse the buffer even if the offset has
changed or the size has shrunk, rather than freeing the buffer.
Change related to: https://bugzilla.gnome.org/show_bug.cgi?id=772841
g_object_ref() forwards the type of its argument nowadays.
./grammar.y:409:14: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
gstchildproxy.c:212:7: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
Otherwise it's possible that we won't be able to start again
depending the implementation. We do start/stop in normal use cases
whenever GST_QUERY_SCHEDULING happens before we are started.
https://bugzilla.gnome.org/show_bug.cgi?id=794149
The flushing state is handled a bit differently, there is no need
to stop flushing in start_complete. This would other result in
unlock_stop being called without unlock_start.
Unlike what the old comment says, there is no need to take the live
lock here, we are still single threaded at this point (app thread
or the state change thread). Also, we will wait for playing state
in create/getrange, no need to do that twice.
https://bugzilla.gnome.org/show_bug.cgi?id=794149
The queue gets filled by the tail, so a query will always be the tail
object, not the head object. Also add a _peek_tail_struct() method to the
GstQueueArray to enable looking at the tail.
With unit test to prevent future regression.
https://bugzilla.gnome.org/show_bug.cgi?id=762875
Position queries with GST_FORMAT_TIME are supposed to return stream
time.
gst_base_sink_get_position() estimates the current stream time on its
own instead of using gst_segment_to_stream_time(), but the algorithm
used was not taking segment.offset into account, resulting in invalid
values when this field was set to a non-zero value.
https://bugzilla.gnome.org/show_bug.cgi?id=792434
Occasionally this test would fail, especially if the system is under load,
because the position query would pick up the last position from the
last buffer timestamp which has a lower timestamp than what we're
looking for. The sleep is long enough, however. It's unclear to me why
exactly this happens but there seems to be some kind of scheduling
issue going on as the streaming thread floods the sink with buffers.
Let's throttle the fakesrc to 100 buffers per second and make the sink
sync to the clock to restore some sanity. It should be totally sufficient
to test what we want to test, and seems to make things reliable here.