We were segfaulting because g_sequence_search was returning the iter_end,
and that iterator does not contain anything and thus should not be used
directly
The old gst_object_has_ancestor will call the new code. This establishes the
symetry with the new gst_object_has_as_parent.
API: gst_object_has_as_ancestor()
In basesink functions gst_base_sink_chain_unlocked(), below code is used to
checking if buffer is late before doing prepare call to save some effort:
if (syncable && do_sync)
late =
gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
GST_CLOCK_EARLY, 0, FALSE);
if (G_UNLIKELY (late))
goto dropped;
But this code has problem, it should calculate jitter based on current media
clock, rather than just passing 0. I found it will drop all the frames when
rewind in slow speed, such as -2X.
https://bugzilla.gnome.org/show_bug.cgi?id=749258
Since frame->priv->discont was cleared earlier,
GST_BASE_PARSE_FLAG_LOST_SYNC was never being set.
Take the chance to refactor the frame creation a bit to
organize the flags setting and reset.
https://bugzilla.gnome.org/show_bug.cgi?id=738237
Subsequent EOS will push on the source pad that already received
EOS and that will make the event function return FALSE. It needs
only to push the first one and only return TRUE for the subsequent
ones.
gst_debug_unset_threshold_for_name() used to go into an
infinite loop when there was more than one category in
the list. This test captures the problem by failing
via timeout.
https://bugzilla.gnome.org/show_bug.cgi?id=748321
Ensure iterator is advanced. The current list iteration code only
advances the iterator (walk) if a match is found, which results
in an infinite loop when more than one entry exists in the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748321
Error out if required build tools (flex, bison, pkg-config)
are not present, instead of printing a message and then
continuing.
Check out submodules when fetching the repositories, so
they're already there and ready later.
Remove some 0.10 cruft.
In order to support some types of protected streams (such as those
protected using DASH Common Encryption) some per-buffer information
needs to be passed between elements.
This commit adds a GstMeta type called GstProtectionMeta that allows
protection specific information to be added to a GstBuffer. An example
of its usage is qtdemux providing information to each output sample
that enables a downstream element to decrypt it.
This commit adds a utility function to select a supported protection
system from the installed Decryption elements found in the registry.
The gst_protection_select_system function that takes an array of
identifiers and searches the registry for a element of klass Decryptor that
supports one or more of the supplied identifiers. If multiple elements
are found, the one with the highest rank is selected.
This commit adds a unit test for the gst_protection_select_system
function that adds a fake Decryptor element to the registry and then
checks that it can correctly be selected by the utility function.
This commit adds a unit test for GstProtectionMeta that creates
GstProtectionMeta and adds & removes it from a buffer and performs some
simple reference count checks.
API: gst_buffer_add_protection_meta()
API: gst_buffer_get_protection_meta()
API: gst_protection_select_system()
API: gst_protection_meta_api_get_type()
API: gst_protection_meta_get_info()
https://bugzilla.gnome.org/show_bug.cgi?id=705991
In order for a decrypter element to decrypt media protected using a
specific protection system, it first needs all the protection system
specific information necessary (E.g. information on how to acquire
the decryption keys) for that stream.
The GST_EVENT_PROTECTION defined in this commit enables this information
to be passed from elements that extract it (e.g. qtdemux, dashdemux) to
elements that use it (E.g. a decrypter element).
API: GST_EVENT_PROTECTION
API: gst_event_new_protection()
API: gst_event_parse_protection()
https://bugzilla.gnome.org/show_bug.cgi?id=705991
