- Apr 20, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
Otherwise PTS and DTS will come out of sync if upstream continues to provide PTS and not DTS, and we have to skip some data from the stream or PTS are not exactly increasing with the duration of each packet. https://bugzilla.gnome.org/show_bug.cgi?id=765260
-
- Apr 15, 2016
-
-
This ensures the following special case is handled properly: 1. Queue is empty 2. Data is pushed, fill level is below the current high-threshold 3. high-threshold is set to a level that is below the current fill level Since mq->percent wasn't being recalculated in step #3 properly, this caused the multiqueue to switch off its buffering state when new data is pushed in, and never post a 100% buffering message. The application will have received a <100% buffering message from step #2, but will never see 100%. Fix this by recalculating the current fill level percentage during high-threshold property changes in the same manner as it is done when use-buffering is modified. https://bugzilla.gnome.org/show_bug.cgi?id=763757
-
Sebastian Dröge authored
If we don't store the value in prev_dts, we would over and over again initialize the DTS from the last known upstream PTS. If upstream only provides PTS every now and then, then this causes DTS to be rather static. For example in adaptive streaming scenarios this means that all buffers in a fragment will have exactly the same DTS while the PTS is properly updated. As our queues are now preferring to do buffer fill level calculations on DTS, this is causing huge problems there. See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this part of the code was introduced. https://bugzilla.gnome.org/show_bug.cgi?id=765096
- Mar 29, 2016
-
-
Ensures we have proper time level estimation for the cases where the incoming buffers have PTS/DTS outside of the segment start/stop values. https://bugzilla.gnome.org/show_bug.cgi?id=762995
-
When going from READY to NULL all element pads are deactivated. If simultaneously the pad is being removed from the element with gst_element_remove_pad() and the pad is unparented, there is a race where the deactivation will assert (g_critical) if the parent is lost at the wrong time. The proposed fix will check parent only once and retain it to avoid the race. https://bugzilla.gnome.org/show_bug.cgi?id=761912
-
- Mar 25, 2016
-
-
Sebastian Dröge authored
Unexpected critical/warning: gstpad.c:4400:gst_pad_push_data:<'':src> Got data flow before segment event https://bugzilla.gnome.org/show_bug.cgi?id=763753
-
Also refactor the existing valve test to actually test the valve, and not just test the EOS mechanism of a pad. https://bugzilla.gnome.org/show_bug.cgi?id=763753
-
- Mar 24, 2016
-
-
Sebastian Dröge authored
CID 1357158
-
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.
-