- Jun 07, 2012
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Wim Taymans authored
Release the object lock before we get the time of the clock because that code might take other locks. Fix potential clock refcount error because we released the object lock but didn't ref the clock.
-
Wim Taymans authored
We always require elements to have an unlock_stop vmethod.
-
Edward Hervey authored
And not the host cpu Conflicts: gst/gstregistry.c
-
- Jun 06, 2012
-
-
Edward Hervey authored
From 1fab359 to 03a0e57
-
Wim Taymans authored
Someone forgot to run make check before pushing...
-
-
Wim Taymans authored
In the dispose handler we first need to release all the request pads and then remove the remaining pads. This is because it is possible that releasing the request pad might also cleanly remove some of the other dynamic pads, like what rtpsession does. https://bugzilla.gnome.org/show_bug.cgi?id=677436
-
Sebastian Dröge authored
Elements are supposed to merge upstream events.
-
Havard Graff authored
Context: Latency configuration should not be messed up because of not-linked pads. In general, one return FALSE on latency distribution causes the "overall" pipeline latency configuration to fail. This shows up as noise in logs (warning). Conflicts: gst/gstpad.c
-
Wim Taymans authored
The name of the event is used to store multiple sticky events of a certain type on a pad. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676859
-
Sebastian Dröge authored
-
Wim Taymans authored
-
Wim Taymans authored
Only serialized events can't be sent on pads that are EOS. Otherwise a seek event would be refused as well. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=677520
-
Wim Taymans authored
-
- Jun 05, 2012
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Wim Taymans authored
Mention that the acceptcaps query does not have to be recursive
-
Wim Taymans authored
-
Wim Taymans authored
-
Wim Taymans authored
Before we can change the caps on a sinkpad with fixed caps we need to unfix the pad caps.
-
Wim Taymans authored
Elements should not rely on core to pause tasks on EOS.
-
Wim Taymans authored
-
- Jun 04, 2012
-
-
Wim Taymans authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Mark Nauwelaerts authored
... since processing might still continue (if e.g. NOT_LINKED) and then proper state (e.g. offset) needs to be maintained (e.g. to arrange for a new frame setup).
-
Sebastian Dröge authored
For non-EOS events things will error out later during data flow but after EOS events no data flow is happening. See bug #677340.
-
Sebastian Dröge authored
Fixes bug #677335.
-
- Jun 02, 2012
-
-
Sebastian Dröge authored
This reverts commit 0f924b92. Sticky events should always return TRUE when pushing and will only cause failures during data flow later.
-
Tim-Philipp Müller authored
-
Sebastian Dröge authored
Otherwise a pipeline where one sticky event fails to be sent will never forward EOS events downstream. This can cause pipelines to wait forever for EOS on errors.
-
Sebastian Dröge authored
Instead of just ignoring failure of pushing sticky events and returning TRUE as if everything is fine.
-
- Jun 01, 2012
-
-
Andre Moreira Magalhaes (andrunko) authored
Fixes bug #677263.
-
Edward Hervey authored
From f1b5a96 to 1fab359
-
- May 31, 2012
-
-
Ported from f3b2dd6f in the 0.10 branch
-
If multiple sources are plugged into the funnel and one of the sources emits an EOS, that event is propogated through the funnel even though other sources connected to the funnel may still be pushing data. This patch waits to send an EOS event until the funnel has received an EOS event on each sinkpad. Ported from d397ea97 in 0.10 branch.
-