A flush-stop event would make a pad unflushing, causing it
to start acting as an activated pad. This, for example,
could lead to the chain function being called when stuff
isn't initialized.
This could happend when setting qtdemux to NULL while a seek
was being handled in the upstream filesrc (in push mode).
This patch makes it check if it is activated before setting
it to unflushing.
There's no need to create these tables with duplicates of the
untranslated error message string constants, we can just use
old-fashioned switch/case and call gettext directly. This also
makes things slightly more thread safe and more robust to bad
input (invalid error codes).
Add a GstStructure to GstElementClass and GstElementFactory. Add setters/getter.
Handle it in the registry code. Print items in gst-inspect.
Fixes#396774.
API: gst_element_class_set_meta_data(), gst_element_factory_get_meta_data_detail()
Added a new query type to retrieve informations about the areas of the
media currently buffered. See bug 623121.
API: gst_query_add_buffering_range
API: gst_query_get_n_buffering_ranges
API: gst_query_parse_nth_buffering_range
Make code including GStreamer headers compile with -Wcast-qual by
maintaining const-ness when casting. Also fix function signature of
gst_byte_writer_set_pos(): the byte writer should not be marked as
const.
https://bugzilla.gnome.org/show_bug.cgi?id=627910
And use it for the fraction comparisons in gstvalue.c instead
of using comparisons by first converting the fractions to double.
Should fix bug #628174.
API: gst_util_fraction_compare()
The problem with both macros is, that they suggest something that isn't true.
If GST_FLOW_IS_FATAL is true, there could still be a problem for many elements
and they should stop what they're currently doing and return that value
upstream (e.g. not-linked in a parser). If GST_FLOW_IS_SUCCESS is false, it
could still be that this is "ok" for the element (e.g. not-linked for a demuxer
on a few of its pads but not all).
It's better to not have these "convenience" macros but instead let people
*think* about the handling of different flow returns, that makes sense for
their element. And we should document the expected handling of flow returns for
different classes of elements in the plugin writer's guide.
Fixes bug #628014.
Adds GST_TAG_APPLICATION_DATA for representing arbitrary private
data that applications might want to store into tags. Exif/id3,
for example, have tags for this.
API: GST_TAG_APPLICATION_DATA
Fixes#626651
When there is a sink inside a bin, the SINK flag is set on the bin. When we are
trying to iterate the source elements, also include the bins with the SINK flag
because they could also contain source elements, in which case they are also a
source.
This solves the case where sending an EOS to a pipeline didn't get dispatched to
all source elements.
See #625597
gst_element_link_many does some magic and creates ghostpads
if needed, but it didn't set the newly created ghostpad to
active if needed. This patch fixes it.
https://bugzilla.gnome.org/show_bug.cgi?id=626784
This is not really necessary here because everything is
initialized from gst_init() already but using G_DEFINE_TYPE()
removes some copy&paste boilerplate code.
In gst_element_get_compatible_pad(), when trying to find a compatible pad on an
element for a given pad, there's no point in checking the element's sink pads
if the pad to link is a sink pad as well, or the element's source pads if the
given pad is a source pad already, since those would never be able to link
anyway. Should speed up linking using the convenience functions a little bit,
or at least reduce debug log output.
The logging is not an atomic operation and because of the multi-threading we end
up with out-of-order log lines. Tools that present the log-file should probably
resort the lines. This change just takes the timestamp a bit closer to the
actual logging.
gst_pad_proxy_getcaps() would return the pad template caps if the other side
returned empty caps or if the intersection of all the caps on the other side
was empty.
https://bugzilla.gnome.org/show_bug.cgi?id=624203
g_printerr() used to do this for us. Also use libc's fprintf() functions,
to make sure the stderr pointer we use is actually compatible with the
libc linked against by GStreamer (which apparently may not always be the
same as what GLib is linked against on windows), and we don't need the
functionality ensured by g_fprintf().
Fixes#625295.