- 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).
-
To make it explicit that we are dealing with uint32 targets Avoids erroneous runtime error: left shift of negative value -1 https://bugzilla.gnome.org/show_bug.cgi?id=789700
-
The gst_ptp_clock_new() does not actually require a name. However, for example the rtpjitterbuffer may create a clock without a name, fail, and fall back to not using the PTP clock. https://bugzilla.gnome.org/show_bug.cgi?id=791034
-
- Nov 09, 2017
-
-
In the same way it's done for other event forwarding.
-
- Oct 11, 2017
-
-
Mathieu Duponchelle authored
When updating the linked list, prev->next = next is correct if prev is actually updated after being set to the head of the list at the start. https://bugzilla.gnome.org/show_bug.cgi?id=788617
-
- Oct 05, 2017
- Sep 18, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 17, 2017
-
-
Sebastian Dröge authored
-
- Sep 08, 2017
-
-
-
This will be needed later when we switch to using -fvisibility=hidden.
-
- Sep 07, 2017
-
-
Add libunwind and dw to the .pc Requires.private. Fixes static library compilation if gstreamer was compiled with one of those dependencies https://bugzilla.gnome.org/show_bug.cgi?id=784795
- Sep 01, 2017
-
-
We would constantly re-post the taglist because posted_avg_rate only gets set to avg_bitrate if parse->priv->post_avg_bitrate is true, so if it's false the posted rate will always differ from the current average rate and we'd queue an update, which leads to us spamming downstream and the application with taglist updates. Fix this by only queuing an update if the average rate will actually be posted. These taglists updates could cause expensive operations on the application side, e.g. in Totem. https://bugzilla.gnome.org/show_bug.cgi?id=786561
-
- Aug 26, 2017
-
-
Thibault Saunier authored
Consider them as an empty array and do not segfault... https://bugzilla.gnome.org/show_bug.cgi?id=786670
-
- Aug 17, 2017
-
-
Tim-Philipp Müller authored
From 48a5d85 to dd9d403
-
Sebastian Dröge authored
Otherwise we might try unscheduling a clock id (that does not exist yet), then the streaming thread waits for id and the state change never continues because the streaming thread is blocked. Also shutting down and flushing and similar should return FLUSHING, not EOS. The stream is not over, we're just not accepting any buffers anymore.
-
- Aug 11, 2017
-
-
Sebastian Dröge authored
After EOS, it is possible for a pad to be resetted by sending either a STREAM_START or SEGMENT event Mimic the same behaviour when receiving STREAM_START/SEGMENT events in queue if we are EOS'd https://bugzilla.gnome.org/show_bug.cgi?id=786056
-