The processing deadline is the acceptable amount of time to process the media
in a live pipeline before it reaches the sink. This is on top of the algorithmic
latency that is normally reported by the latency query. This should make
pipelines such as "v4lsrc ! xvimagesink" not claim that all frames are late
in the QoS events. Ideally, this should replace max_lateness for most applications.
https://bugzilla.gnome.org/show_bug.cgi?id=640610
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
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.
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.
Sub-class may want to decide to go passthrough/in-place by inspecting
the support meta APIs. This patch duplicates the check for this mode,
so we still don't do uneeded allocation query while we allow sub-classes
to switch the behaviour during it's own decide_allocation call.
Notice that such sub-class need to reset the class to non-passthrough in
set_caps() in order for decide_allocation to be called again. This is
needed otherwise we'd be doing an allocation query in element in which
it make no sense (notably capsfilter).
https://bugzilla.gnome.org/show_bug.cgi?id=791453
Add a gst_base_src_submit_buffer_list() function that allows subclasses
to produce a bufferlist containing multiple buffers in the ::create()
function. The buffers in the buffer list will then also be pushed out
in one go as a GstBufferList. This can reduce push overhead
significantly for sources with packetised inputs (such as udpsrc)
in high-throughput scenarios.
The _submit_buffer_list() approach was chosen because it is fairly
straight-forward, backwards-compatible, bindings-friendly (as opposed
to e.g. making the create function return a mini object instead),
and it allows the subclass maximum control: the subclass can decide
dynamically at runtime whether to return a list or a single buffer
(which would be messier if we added a create_list virtual method).
https://bugzilla.gnome.org/show_bug.cgi?id=750241
If we're adding to the tail of the queue, it's because we're converting
a gap event, so don't block there it means we're calling from the output
thread.
https://bugzilla.gnome.org/show_bug.cgi?id=784911
Add a comment for when the state matters. Use a local var for priv in
update_time_level() to improve readability. Move the our_latency local
var below the query results checks.
We want to skip serialization for FLUSH_STOP events (apparently). We can
simplify the code to add it to the top-level conditions. There was nothing
done in the first code path if the event was FLUSH_STOP.
Just queue it like any other serialized event. This way we don't need to
check if there still are buffers in the queue.
Validated with the tests and gst-launch-1.0 pipelines.
Don't copy the whole event struct. Set the input params when we call the
forwarding helper. Initialize the internal fields and return values in the
helper.
Otherwise check_events() will not remove the GAP event (as the queue
tail is not the event anymore but the GAP buffer), then the GAP buffer
is handled, then the GAP event is handled again, ... forever.
This ensures that they really get processed in order with
buffers. Just waiting for the queue to be empty is sometimes not
enough as the buffers are dropped from the pad before the result is
pushed to the next element, sometimes resulting in surprising
re-ordering.
In the case an aggregator is created and pads are requested but only
linked later, we end up never updating the upstream latency.
This was because latency queries on pads that are not linked succeed,
so we never did a new query once a live source has been linked, so the
thread was never started.
https://bugzilla.gnome.org/show_bug.cgi?id=757548
