Adds gst_byte_reader_masked_scan_uint32_peek just like
GstAdapter has a _peek and non _peek version
Upgraded tests to check that the returned value is correct in the
_peek version
API: gst_byte_reader_masked_scan_uint32_peek
https://bugzilla.gnome.org/show_bug.cgi?id=728356
Adds a utility struct that is capable of storing and aggregating flow returns
associated with pads.
This way all demuxers will have a standard function to use and have the
same expected results.
Includes tests.
https://bugzilla.gnome.org/show_bug.cgi?id=709224
This defaults to TRUE and if it is set to FALSE it is the subclasses
responsibility to return GST_FLOW_EOS from the create() vmethod once
the stream is done.
Adds a variant of the _push function that doesn't check the queue limits
before adding the new item. It is useful when pushing an element to the
queue shouldn't lock the thread.
One particular scenario is when the queue is used to serialize buffers
and events that are going to be pushed from another thread. The
dataqueue should have a limit on the amount of buffers to be stored to
avoid large memory consumption, but events can be considered to have
negligible impact on memory compared to buffers. So it is useful to be
used to push items into the queue that contain events, even though the
queue is already full, it shouldn't matter inserting an item that has
no significative size.
This scenario happens on adaptive elements (dashdemux / mssdemux) as
there is a single download thread fetching buffers and putting into the
dataqueues for the streams. This same download thread can als generate
events in some situations as caps changes, eos or a internal control
events. There can be a deadlock at preroll if the first buffer fetched
is large enough to fill the dataqueue and the download thread and the
next iteration of the download thread decides to push an event to this
same dataqueue before fetching buffers to other streams, if this push
locks, the pipeline will be stuck in preroll as no more buffers will be
downloaded.
There is a somewhat common practice in dash streams to have a single
very large buffer for audio and one for video, so this will always
happen as the download thread will have to push an EOS right after
fetching the first buffer for any stream.
API: gst_data_queue_push_force
https://bugzilla.gnome.org/show_bug.cgi?id=705694
This function works just like gst_data_queue_pop, but it doesn't
remove the object from the queue.
Useful when inspecting multiple GstDataQueues to decide from which
to pop the element from.
Add: gst_data_queue_peek
This is a queue which has the same API as GQueue, except that:
* It uses an array, instead of a doubled-linked-list
* The array can only grow.
This code is not-threadsafe. It is up to the owner to make sure the
proper locking is taken before calling this API.
Rename gst_base_sink_wait_eos() to gst_base_sink_wait() to avoid confusion and
introspection problems with the ::wait_eos vmethod. Also this method can be used
to wait for other things than EOS. Update the docs a little.
Rename gst_base_transform_suggest to gst_base_transform_reconfigure_sink because
that is what it does. Also remove the caps and size because that is not needed.
Rename gst_base_transform_reconfigure to gst_base_transform_reconfigure_src.
Remove some old unused code in capsfilter.
Conflicts:
libs/gst/base/gstbasetransform.c
libs/gst/controller/gstinterpolationcontrolsource.c
libs/gst/controller/gstlfocontrolsource.c
plugins/elements/gstfilesrc.c
Dit not merge controller or basetransform changes.
Rename the last-buffer property to last-sample and make it return the new
GstSample type so that we can include caps and timing info in one nice bundle.
There's no code that uses it other than multiqueue, so make it private
to multiqueue for now. That way we can also do optimisations that
require API/ABI breaks. If anyone ever wants to use it, we can still
make it public again.
