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
Various plugins use special values (0 or G_MAXUINT32) as an
invalid/unset group_id, but nothing guarantees a groupid won't have
that value.
Instead define a value which group_id will never have and make
gst_group_id_next() always return a value different from that.
API: GST_GROUP_ID_INVALID
Convenience function to just grab all pending data
from the harness, e.g. if we just want to check if
it matches what we expect and we don't care about
the chunking or buffer metadata.
Based on patch by: Havard Graff <havard.graff@gmail.com>
An object that can be waited on and asked for asynchronous values.
In much the same way as promise/futures in js/java/etc
A callback can be installed for when the promise changes state.
Original idea by
Jan Schmidt <jan@centricular.com>
With contributions from
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=789843
Add convenience API that iterates over all pads, sink pads or
source pads and makes sure that the foreach function is called
exactly once for each pad.
This is a KISS implementation. It doesn't use GstIterator and
doesn't try to do clever things like resync if pads are added
or removed while the function is executing. We can still do that
in future if we think it's needed, but in practice it will
likely make absolutely no difference whatsoever, since these
things will have to be handled properly elsewhere by the element
anyway if they're important.
After all, it's always possible that a pad is added or removed
just after the iterator finishes iterating, but before the
function returns.
This is also a replacement for gst_aggregator_iterate_sink_pads().
https://bugzilla.gnome.org/show_bug.cgi?id=785679
This stores debug logs in memory per thread and uses up to a
configurable amount of bytes per thread for the logs. Inactive threads
are timed out after a configurable amount of time.
https://bugzilla.gnome.org/show_bug.cgi?id=785035
gst_protection_filter_systems_by_available_decryptors() takes an array
of strings and returns a new array of strings filtered by the available
decryptors for them so the ones you get are the ones that you should be
able to decrypt.
https://bugzilla.gnome.org/show_bug.cgi?id=770107
This is a meta that generically allows to attach additional reference
timestamps to a buffer, that don't have to relate to the pipeline clock
in any way.
Examples of this could be an NTP timestamp when the media was captured,
a frame counter on the capture side or the (local) UNIX timestamp when
the media was captured.
https://bugzilla.gnome.org/show_bug.cgi?id=779213
This is useful for integration with other event loops that work by
polling file descriptors. G_IO_IN will always be set whenever a message
is available currently.
https://bugzilla.gnome.org/show_bug.cgi?id=776126
This is to help bindings access properties of type GST_TYPE_ARRAY.
This function will get/set the property and convert form/to
GValueArray.
New API:
gst_util_set_object_array
gst_util_get_object_array
https://bugzilla.gnome.org/show_bug.cgi?id=753754
This adds a binding friendly interface to get and set arrays
and list into GstStructure.
New API:
- gst_structure_set_array
- gst_structure_set_list
- gst_structure_get_array
- gst_structure_get_list
https://bugzilla.gnome.org/show_bug.cgi?id=753754
This is an API break but that API has not been released yet.
We are passing a flag rather than a simple boolean as we can imagine
to implement more features in the future for example to retrieve a
stack trace for all the threads, etc..
Retrieving source file and line numbers is pretty
expensive while getting a stack trace, this new argument
allows the user to decide to retrieve a backtrace
without those infos instead which is much faster.
For example running $ GST_LEAKS_TRACER_STACK_TRACE=1 GST_DEBUG=GST_TRACER:7 \
GST_TRACERS=leaks time gst-launch-1.0 videotestsrc num-buffers=1 ! fakesink:
* With simple stack traces:
0.04s user 0.02s system 99% cpu 0.060 total
* With full stack traces:
0.66s user 0.23s system 96% cpu 0.926 total
https://bugzilla.gnome.org/show_bug.cgi?id=775423
As an usecase of URI fragment, it can indicate temporal or spatial
dimension of a media stream. To easily parse key-value pair,
newly added gst_uri_get_media_fragment_table () API will provide
the table of key-value pair likewise URI query.
See also https://www.w3.org/TR/media-frags/https://bugzilla.gnome.org/show_bug.cgi?id=774830
Allows proxying the control interface from one property on one GstObject
to another property (of the same type) in another GstObject.
E.g. in a parent-child relationship, one may need to
gst_object_sync_values() on the child and have a binding (set elsewhere)
on the parent update the value.
Note: that this doesn't solve GObject property forwarding and must be
taken care of by the implementation manually or using GBinding.
https://bugzilla.gnome.org/show_bug.cgi?id=774657
Use grep -o to grab the log message only. This makes it work with colored log
files too. Prefilter the log to not catch tracer classes.
Update the commandline for the script in the docs.
In many parts of the code we raise streaming error when the flow
goes wrong, and each time we create more or less similare error
message. Also that message does not let the application know what
has actually gone wrong. In the new API we add a "flow-return" detail
field inside the GstMessage so that the application has all the information
if it needs it.
API:
GST_ELEMENT_FLOW_ERROR
https://bugzilla.gnome.org/show_bug.cgi?id=770158
Fixes g-i warning "Gst: Constructor return type mismatch
symbol='gst_element_message_new_details' constructed='Gst.Element'
return='Gst.Structure'".
This is a newly-added function in git that has not been in a stable
release yet, so it's fine to rename it. It's also only used indirectly
via macros.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
A new event which precedes EOS in situations where we
need downstream to unblock any pads waiting on a stream
before we can send EOS. E.g, decodebin draining a chain
so it can switch pads.
https://bugzilla.gnome.org/show_bug.cgi?id=768995
Redirection messages are already used in fragmented sources and in
uridecodebin, so it makes sense to introduce these as an official message
type.
https://bugzilla.gnome.org/show_bug.cgi?id=631673
We don't do calculations with different units (buffer offsets and bytes)
anymore but have functions for:
1) getting the number of bytes since the last discont
2) getting the offset (and pts/dts) at the last discont
and the previously added function to get the last offset and its distance from
the current adapter position.
https://bugzilla.gnome.org/show_bug.cgi?id=766647
API: gst_buffer_prev_offset
API: gst_buffer_get_offset_from_discont
The gst_buffer_get_offset_from_discont() method allows retrieving the current
offset based on the GST_BUFFER_OFFSET of the buffers that were pushed in.
The offset will be set initially by the GST_BUFFER_OFFSET of
DISCONT buffers, and then incremented by the sizes of the following
buffers.
The gst_buffer_prev_offset() method allows retrievent the previous
GST_BUFFER_OFFSET regardless of flags. It works in the same way as
the other gst_buffer_prev_*() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=766647
We already had a _full() version, but having that alone seems inconsistent.
Add a non-full version that mirrors the behaviour of gst_pad_link() vs
gst_pad_link_full().
This calls a function from another thread, asynchronously. This is to be
used for cases when a state change has to be performed from a streaming
thread, directly via gst_element_set_state() or indirectly e.g. via SEEK
events.
Calling those functions directly from the streaming thread will cause
deadlocks in many situations, as they might involve waiting for the
streaming thread to shut down from this very streaming thread.
This is mostly a convenience function around a GThreadPool and is for example
used by GstBin to continue asynchronous state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
g_signal_emit_by_name() is not like gst_app_src_push_buffer() due to reference
counting limitations of signals, it does *not* take ownership of the buffer.
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
This is a useful function to automatically add ghost pads when linking
two elements across bin boundaries without know their exact parentage.
e.g. when using gst_parse_bin_from_description (with or without it ghosting pads),
one can simply retreive the src/sink pads from the bin to link to another pad.
Similar functionality is provided by gst_element_link_pads{_full}() however only
by pad name rather than by actual pads.
API: gst_pad_link_maybe_ghosting_full
https://bugzilla.gnome.org/show_bug.cgi?id=764176
Pretty much every single element does
gst_element_class_add_pad_template (element_class,
gst_static_pad_template_get (&some_templ));
which is both confusing and unnecessary. We might just
as well add a function to do that in one step.
https://bugzilla.gnome.org/show_bug.cgi?id=762778
advanced-dataaccess.xml:1210: element listitem: validity error : Element
listitem content does not follow the DTD, expecting (...),
got (para CDATA para )
</listitem>
Similar to the stress test functions for buffers that has a callback to
create the buffer to be pushed, it's useful to have functions that use a
callback to create the event to be pushed.
API: gst_harness_stress_push_event_with_cb_start()
API: gst_harness_stress_push_event_with_cb_start_full()
API: gst_harness_stress_send_upstream_event_with_cb_start()
API: gst_harness_stress_push_upstream_event_with_cb_start_full()
https://bugzilla.gnome.org/show_bug.cgi?id=761932
