- Mar 24, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Mar 23, 2016
-
-
POSIX standards requires strsignal() to return a pointer to a char, not a const pointer to a char. [1] On uClibc, and possibly other libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares const char *strsignal (int sig) which causes a type error. [1] man 3 strsignal https://bugzilla.gnome.org/show_bug.cgi?id=763567
-
- Mar 22, 2016
-
-
Sebastian Dröge authored
First load all system presets, then all from the environment variable, then from the app directory, then from the user directory. Any one in the chain with the highest version completely replaces all previous ones, later ones with lower versions are merged in without replacing existing presets. This is basically the same behaviour as before, just that GST_PRESET_PATH is inserted as another source of directories between the system and app presets. It was added in ca08af1f, but was accidentially overriding the user preset path there. Which caused inconsistent behaviour as new presets were still stored in the system path, just not loaded from there. Meaning you could store a new preset (in the user path), just for GstPreset to not find it anymore later (because it only looked in the GST_PRESET_PATH instead of the user path). https://bugzilla.gnome.org/show_bug.cgi?id=764034
-
- Mar 21, 2016
-
-
and also change the description accordingly since function returns an incremented caps object or NULL if there is no caps set. https://bugzilla.gnome.org/show_bug.cgi?id=763912
- Mar 18, 2016
-
-
Jan Schmidt authored
Add a test which checks that not-linked pads continue to output data after linked pads have gone EOS https://bugzilla.gnome.org/show_bug.cgi?id=763770
-
Jan Schmidt authored
Ensure that not-linked pads will drain out at EOS by correctly detecting the EOS condition based on the EOS pad flag (which indicates we actually pushed an EOS), and make sure that not-linked pads are woken when doing EOS processing on linked pads. https://bugzilla.gnome.org/show_bug.cgi?id=763770
- Mar 15, 2016
-
-
If an application calls gst_pad_query_caps from its "have-type" signal handler, then the query fails because typefind->caps has not been set yet. This patch sets typefind->caps in the object method handler, before the signal handlers are called. https://bugzilla.gnome.org/show_bug.cgi?id=763491
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Mar 14, 2016
-
-
Sebastian Dröge authored
typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler https://bugzilla.gnome.org/show_bug.cgi?id=763491
-
Sebastian Dröge authored
Many parsers are storing tags only in pre_push_frame(), if we wouldn't check afterwards we would push buffers before those tags and a lot of code assumes that tags are available before preroll. https://bugzilla.gnome.org/show_bug.cgi?id=763553
-
-
- Mar 12, 2016
-
-
Sebastian Dröge authored
Revert "typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler" This reverts commit 0835c3d6. It causes deadlocks in decodebin, which currently would deadlock if the caps are already on the pad in have-type and are forwarded while copying the sticky events (while holding the decodebin lock)... as that might cause the next element to expose pads, which then calls back into decodebin and takes the decodebin lock. This needs some more thoughts.
-
Sebastian Dröge authored
typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler https://bugzilla.gnome.org/show_bug.cgi?id=763491
-
- Mar 10, 2016
- Mar 09, 2016
-
-
Sebastian Dröge authored
-
-
- Mar 07, 2016
-
-
Víctor Manuel Jáquez Leal authored
The alias define GST_TYPE_PARENT_BUFFER_META_API_TYPE is wrong and breaks the usage of gst_buffer_get_parent_buffer_meta(). This patch fixes the GType alias and make another alias to keep the API compatibility guarded by GST_DISABLE_DEPRECATED. Also added a unit test. https://bugzilla.gnome.org/show_bug.cgi?id=763112
-
- Mar 02, 2016
-
-
Sebastian Dröge authored
gst_structure_new_empty() is not returning NULL in any valid scenarios, checking for NULL here is useless. Especially because we would dereference any NULL right after the NULL check again. CID 1352037. We previously check if the string ends on .class, as such strrchr() should return something non-NULL. Add an assertion for that. CID 1349642.
-
- Mar 01, 2016
-
-
Tim-Philipp Müller authored
Make gtk-doc happy.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Feb 29, 2016
-
-
Sebastian Dröge authored
This reverts commit 894c67e6.
-
Sebastian Dröge authored
This reverts commit 05700a70.
-
Sebastian Dröge authored
There is no corresponding API for that in GLib and nobody could've ever used these macros without compiler errors anyway.
-
Sebastian Dröge authored
Otherwise the GSource can look into our already destroyed bus where the GPollFD is stored. https://bugzilla.gnome.org/show_bug.cgi?id=762849
-
- Feb 28, 2016
-
-
-
-
Tim-Philipp Müller authored
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
-
- Feb 27, 2016
-
-
Tim-Philipp Müller authored
-
- Feb 26, 2016
-
-
Sebastian Dröge authored
From b64f03f to 6f2d209
-
This happens if the process runs out of file descriptors. Better print a critical warning instead of just crashing. https://bugzilla.gnome.org/show_bug.cgi?id=762702
-
- Feb 25, 2016
-
-
Thiago Santos authored
When holding a regular ref it will cause the GstBus to never reach 0 references and it won't be destroyed unless the application explicitly calls gst_bus_remove_signal_watch(). Switching to weakref will allow the GstBus to be destroyed. The application is still responsible for destroying the GSource. https://bugzilla.gnome.org/show_bug.cgi?id=762552
-
Sebastian Dröge authored
-
- Feb 23, 2016
-
-
Otherwise people reading the manual will expect it to always succeed :) https://bugzilla.gnome.org/show_bug.cgi?id=728326
-