- Mar 28, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Mar 18, 2018
-
-
This is in the same vein as for all other features. Some systems might not allow unaligned read.
-
- Feb 14, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
So new-in-1.12 index actually has some entries.
-
The functions were introduced in version 1.12.1, GstFlowCombiner was introduced in 1.4. https://bugzilla.gnome.org/show_bug.cgi?id=788778
-
- Jan 26, 2018
-
-
Tim-Philipp Müller authored
Do this for all method invoke functions for consistency. https://bugzilla.gnome.org/show_bug.cgi?id=750154
-
"Label ‘out’ used but not defined", since it's also used by the USE_MEDIAN_PRE_FILTERING branch. https://bugzilla.gnome.org/show_bug.cgi?id=785631
-
Tim-Philipp Müller authored
Fix refcounting issue when plugin was loaded already. gst_plugin_load() is supposed to return a ref, so it must always return a ref. This also fixes the gstplugin unit test on windows where fork is not available and where test_load_coreelements() would unref a plugin ref it didn't get and then mess up the internal registry plugin list state for the next test, in case where the test registry does not exist yet.
-
Tim-Philipp Müller authored
in set_threshold_from_string().
-
- Jan 17, 2018
-
-
Sebastian Dröge authored
Annotate them as such.
-
Sebastian Dröge authored
Something might handle it from a sync message handler and call back into downloadbuffer, causing a deadlock.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
It's possible to replace the bus with NULL/None
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jan 16, 2018
-
-
The following case can happen when two thread try to activate and deactivate a pad at the same time: T1: starts to deactivate, calls pre_activate(), sets in_activation to TRUE and carries on T2: starts to activate, calls pre_activate(), in_activation is TRUE so it waits on the GCond T1: calls post_activate(), tries to acquire the streaming lock .. but can't because T2 is currently holding it With this patch, the deadlock will no longer happen but does not solve the problem that: T2: will resume activation of the pad, set the pad mode to the target one (PUSH or PULL) and eventually the streaming lock gets released. T1: is able to finish calling post_activate() ... but ... the pad wasn't deactivated (T2 was the last one to "activate" the pad. https://bugzilla.gnome.org/show_bug.cgi?id=792341
-
- Jan 15, 2018
-
-
Otherwise we would deadlock waiting forever for the streaming lock to be released https://bugzilla.gnome.org/show_bug.cgi?id=792341
-
- Dec 07, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Dec 06, 2017
-
-
When actually pushing an event, if we get GST_FLOW_CUSTOM_SUCCESS_1 (which is the conversion of GST_PAD_PROBE_HANDLED return value), don't consider the stick event push as ignored, but as handled
-
If multiple probes are set on a pad and one probe returns either GST_PAD_PROBE_HANDLED or GST_PAD_PROBE_DROPPED we need to stop calling the remaining probes. https://bugzilla.gnome.org/show_bug.cgi?id=787243
-
For linked elements, the resulting gst_bin_iterate_sorted() will properly return elements from sink to sources. If we have some elements that are not linked, we *still* want to ensure that we return: * In priority any sinks * Last of all any sources * And in between any element which is neither source nor sink For this to work, when looking for the next candidate element, not only check the degree order, but if there are two candidates with the same degree order, prefer the non-source one. Amongst other things, this fixes the case where we activating a bin containing unlinked sources and other elements. Without this we could end up activating sources (which might start adding pads to be linked) before other (to which those new source element pads might be linked) are not activated https://bugzilla.gnome.org/show_bug.cgi?id=788434
-
Sebastian Dröge authored
This is consistent with how it works for GstEvent already.
-
Not only if a match pattern was set originally via GST_DEBUG. Patterns might be set programmatically as well after all.
-
When registering a new debug category after gst_init(), simply check the existing patterns against that new category. No need to iterate over all categories and recheck them all against the existing patterns. Also, no need to re-parse the existing pattern string set via GST_DEBUG and add the same set of match patterns all over again to the existing list of match patterns every time we register a new debug category. Combined with iterating all debug categories on a change this would make adding debug categories after gst_init() very very very slow.
-
- Dec 01, 2017
-
-
Because
-
The array provided by backtrace_symbols needs to be freed.
-
The check for dropping precision was wrong when sxx and syy were negative. if they are negative then "G_MAXINT64 - val" would always overflow The check was meant to use G_MININT64 (like in the loop contained just after).
-
-
An upstream query will take a ref on the internal proxypad, and can hence end up owning the last reference to that pad, causing a crash.
-
Doing calculations with GST_CLOCK_STIME_NONE would result in completely bogus levels
-
The following could happen previously: * T1: calls gst_pad_set_active() * T2: currently (de)activating it * T1: gst_pad_set_active() returns, caller assumes that the pad has completed the requested (de)activation ... whereas it is not the case since the actual (de)activation in T2 might still be going on. To ensure atomicity of pad (de)activation, we use a internal variable (and cond) to ensure only one thread at a time goes through the actual (de)activation block https://bugzilla.gnome.org/show_bug.cgi?id=790431
-
checking whether we already were in the target GstPadMode was being done too early and there was the risk that we *would* end up (de)activating a pad more than once. Instead, re-do the check for pad mode when entering the final pad (de)activation block. https://bugzilla.gnome.org/show_bug.cgi?id=790431
-
Nothing guaranteed that off+size wouldn't exceed a 2**64 value. Instead we reverse the operation and use a subtraction.
-
Make sure the whole calculation is done with 64bit unsigned values (To be ready for people want to typefind exabyte files).
-