- Aug 19, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Aug 16, 2016
-
-
In ringbuffer mode we need to make sure we post buffering messages *before* blocking to wait for data to be drained. Without this, we would end up in situations like this: * pipeline is pre-rolling * Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread is blocking downstream (i.e. not pulling from upstream/queue2). * Therefore pipeline has pre-rolled ... * ... but queue2 hasn't filled up yet, therefore the application waits for the buffering 100% messages before setting the pipeline to PLAYING * But queue2 can't post that message, since the 100% message will be posted *after* there is room available for that last buffer. https://bugzilla.gnome.org/show_bug.cgi?id=769802
-
When dealing with small-ish input data coming into queue2, such as adaptivedemux fragments, we would never take into account the last <200ms of data coming in. The problem is that usually on TCP connection the download rate gradually increases (i.e. the rate is lower at the beginning of a download than it is later on). Combined with small download time (less than a second) we would end up with a computed average input rate which was sometimes up to 30-50% off from the *actual* average input rate for that fragment. In order to fix this, force the average input rate calculation when we receive an EOS so that we take into account that final window of data. https://bugzilla.gnome.org/show_bug.cgi?id=768649
-
- Aug 13, 2016
-
-
Tim-Philipp Müller authored
It's what introspection.mak does as well. Should fix spurious build failures on gnome-continuous.
-
Tim-Philipp Müller authored
So CC="ccache gcc" works properly.
-
-
- Jul 25, 2016
-
-
Other pads that are waiting for the stream on the selected pad to advance before they finish waiting themselves should be given the chance to do so when the selected pad goes EOS. Fixes problems where input streams can end up waiting forever if the active stream goes EOS earlier than their own end time.
-
Sebastian Dröge authored
baseparse: Make sure to not create an invalid event order when generating the default CAPS event because of a GAP event There must be a SEGMENT event before the GAP event, and SEGMENT events must come after any CAPS event. We however did not produce any CAPS yet, so we need to ensure to insert the CAPS event before the SEGMENT event into the pending events list. https://bugzilla.gnome.org/show_bug.cgi?id=766970
-
- Jul 04, 2016
-
-
Needed so GstBus can be tracked by the leaks tracer. https://bugzilla.gnome.org/show_bug.cgi?id=768141
-
Ensure we do not attempt to destroy the current range. Doing so causes the current one to be left dangling, and it may be dereferenced later, leading to a crash. This can happen with a very small queue2 ring buffer (10000 bytes) and 4 kB buffers. repro case: gst-launch-1.0 fakesrc sizetype=2 sizemax=4096 ! \ queue2 ring-buffer-max-size=1000 ! fakesink sync=true https://bugzilla.gnome.org/show_bug.cgi?id=767688
-
- Jul 01, 2016
-
-
This is an update on c9b68488 multiqueue: Fix not-linked pad handling at EOS While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS, it would break the same issue when *downstream* returns GST_FLOW_EOS (which can happen for example when downstream decoders receive data from after the segment stop). GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it and not when a GST_EVENT_EOS has gone through it. In order to handle both cases, also take into account the last flow return. https://bugzilla.gnome.org/show_bug.cgi?id=763770
-
- Jun 27, 2016
-
-
This patch handle the case when you have 1 pad (so the fast path is being used) but this pad is removed. If we are in allow-not-linked, we should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED and ignore the meaningless return value obtained from pushing. https://bugzilla.gnome.org/show_bug.cgi?id=767413
-
Sebastian Dröge authored
If we were in PAUSED, the current clock time and base time don't have much to do with the running time anymore as the clock might have advanced while we were PAUSED. The system clock does that for example, audio clocks often don't. Updating the start time in PAUSED will cause a) the wrong position to be reported, b) step events to step not just the requested amount but the amount of time we spent in PAUSED. The start time should only ever be updated when going from PLAYING to PAUSED to remember the current running time (to be able to compensate later when going to PLAYING for the clock time advancing while PAUSED), not when we are already in PAUSED. Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com> The updating of the start time when the state is lost was added in commit ba943a82 to fix the position reporting when the state is lost. This still works correctly after this change. https://bugzilla.gnome.org/show_bug.cgi?id=739289
-
- Jun 17, 2016
-
-
When GST_PAD_PROBE_EVENT_FLUSH is used, the probes already have a data type and it is not needed to automatically add the default types. Without this, EVENT_FLUSH probes that didn't specify a data type would be called also for other data such as buffers. https://bugzilla.gnome.org/show_bug.cgi?id=762330
- 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
-
-
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
-
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
-
-
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
-
-
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
-