- Jun 09, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- May 20, 2016
-
-
Sebastian Dröge authored
... when flushing and deactivating pads. Otherwise downstream might have a query that was already unreffed by upstream, causing crashes or other interesting effects. https://bugzilla.gnome.org/show_bug.cgi?id=763496
-
- May 19, 2016
-
-
Sebastian Dröge authored
Make it explicit that the pad is only blocked while the callback is running, and the pad will be unblocked again once the callback returned. If BLOCK and IDLE behaviour is needed, both need to be used. https://bugzilla.gnome.org/show_bug.cgi?id=766002
-
Sebastian Dröge authored
The subclass should do that already, but just in case do it ourselves too as a fallback. Without this, e.g. playbin will just wait forever if this fails because it is triggered as part of an ASYNC state change.
-
- May 16, 2016
-
-
Jan Schmidt authored
When doing a transition from PLAYING to PLAYING, we will fail to forward an EOS message on the bus, and noone else will ever send it because there'll be no actual state changed message. Allow EOS through directly in that case.
-
- May 12, 2016
-
-
Sebastian Dröge authored
The other signal handlers of the type-found signal might have reactivated typefind in PULL mode already, pushing a CAPS event at that point would cause deadlocks and is in general unexpected by elements that are in PULL mode. https://bugzilla.gnome.org/show_bug.cgi?id=765906
-
- May 11, 2016
-
-
Sebastian Dröge authored
When activating a pad in PULL mode, it might already be in PUSH mode. We now first try to deactivate it from PUSH mode and then try to activate it in PULL mode. If the activation fails, we would set the pad to flushing and set it back to its old mode. However the old mode is wrong, the pad is not in PUSH mode anymore but in NONE mode. This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream actually fails to go into PULL mode after first PUSHING data to typefind.
-
- May 06, 2016
-
-
Guillaume Desmottes authored
The root element was not unreffed when iterating over ancestors. https://bugzilla.gnome.org/show_bug.cgi?id=765961
-
- Apr 28, 2016
-
-
Sebastian Dröge authored
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.
-
- Apr 26, 2016
-
-
Sebastian Dröge authored
Passing years > 9999, months > 12 or days > 31 to gst_date_time_new() will cause an assertion and generally does not make much sense. Instead consider it as a parsing error like hours > 24 and return NULL.
-
- 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
-
-
-
Carlos Rafael Giani authored
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
-
-
Edward Hervey authored
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
-
Stian Selnes authored
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
-
Havard Graff authored
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
-
-
Anthony G. Basile authored
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
-
-
-
Aurélien Zanelli authored
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
-
-
Romain Picard authored
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
-
Carlos Rafael Giani authored
-