We need all relevant events of a segment to have consistent seqnum:
* GST_EVENT_SEGMENT
* GST_EVENT_EOS
If we are push-based and create a new segment, use the same seqnum
as the upstream event.
If we are pull-based, use the seqnum of that newly created segment
event everywhere
strncpy() is assumed to be for strings so the compiler assumes that
it will need an extra byte for the string-terminaning NULL.
For cases where we know it's actually "binary" data, just copy it
with memcpy.
https://bugzilla.gnome.org/show_bug.cgi?id=795756
GstBitWriter provides a bit writer that can write any number of
bits into a memory buffer. It provides functions for writing any
number of bits into 8, 16, 32 and 64 bit variables.
https://bugzilla.gnome.org/show_bug.cgi?id=707543
Meson supports building both static and shared libraries in a single
library() call. It has the advantage of reusing the same .o objects and
thus avoid double compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=794627
And make the drop() functions expect a 0-based index too,
this addresses a longstanding FIXME. This will not break
backward compatibility, because the drop() functions
were previously only meant to be used with the index
returned by find().
https://bugzilla.gnome.org/show_bug.cgi?id=795156
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
As we do that for serialized events as well, and the subclass will
most likely need to access pad->segment to make its decisions,
doing that from the sinkpad's streaming threads was racy.
