- Sep 16, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Sep 11, 2018
-
-
Jan Schmidt authored
Add a check for gst_segment_offset_running_time() that values are taken directly from the segment base if possible.
-
Jan Schmidt authored
Fixes for gst_segment_position_from_running_time_full() when converting running_times that precede the segment start (or stop in a negative rate segment) The return value was incorrectly negated in those cases. Add some more unit test checks for those cases, and especially for segments with offsets.
-
- Sep 08, 2018
-
-
gst_element_post_message() takes ownership of the message so we need to increase its refcount until we no longer require access to its data (context_type). https://bugzilla.gnome.org/show_bug.cgi?id=797099
-
- Sep 03, 2018
-
-
- Aug 31, 2018
-
-
Philippe Normand authored
The avg_bitrate is an unsigned int, so the gst_util_uin64_scale() function can't be used for it, as it expects signed integers for the fraction parts arguments. https://bugzilla.gnome.org/show_bug.cgi?id=797054
-
Sebastian Dröge authored
-
Sebastian Dröge authored
This reverts commit 794944f7. Accumulating non-live latency values generally makes no sense and often gives invalid results with min>max
-
Sebastian Dröge authored
This reverts commit f5783e1c.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
And only ever use the non-live values if all pads are non-live, otherwise only use the results of all live pads. It's unclear what one would use the values for in the non-live case, but by this we at least pass them through correctly then. This is a follow-up for 794944f7, which causes wrong latency calculations if the first pad is non-live but a later pad is actually live. In that case the live values would be accumulated together with the values of the non-live first pad, generally causing wrong min/max latencies to be calculated.
-
- Aug 02, 2018
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
pad: Ensure that the pad is blocked for IDLE probes if they are called from the streaming thread too IDLE probes that are directly called when being added will increase / decrease the "number of IDLE probes running" counter around the call, but when running from the streaming thread this won't happen. This has the effect that when running from a streaming thread it is possible to push serialized events or data out of the pad without problems, but otherwise it would deadlock because serialized data would wait for the IDLE probe to finish first (it is blocking after all!). With this change it will now always consistently deadlock instead of just every once in a while, which should make it obvious why this happens and prevent racy deadlocks in application code. https://bugzilla.gnome.org/show_bug.cgi?id=796895
-
Sebastian Dröge authored
And make use of it in the typefind element. It's useful to distinguish between the different errors why typefinding can fail, and especially to not consider GST_FLOW_FLUSHING as an actual error. https://bugzilla.gnome.org/show_bug.cgi?id=796894
-
-
Sebastian Dröge authored
Otherwise downstream will consider the pipeline not live if the active pad is live, even though some inactive pads might be live and might require a non-zero latency configuration. https://bugzilla.gnome.org/show_bug.cgi?id=796901
-
- Jul 30, 2018
-
-
Mathieu Duponchelle authored
-
- Jul 25, 2018
-
-
Sebastian Dröge authored
-
- Jul 19, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
gst_base_transform_transform_caps can return NULL in various conditions thus we should not treat its result as valid caps. In all other places NULL is properly handled.
-
- Jul 18, 2018
-
-
- May 21, 2018
-
-
- May 20, 2018
-
-
Under MSYS2 glib-mkenums is an executable and has a .exe extension and the path does not end with "glib-mkenums". Make the script compare the path without the file extension instead. https://bugzilla.gnome.org/show_bug.cgi?id=796273
-
- May 17, 2018
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- May 14, 2018
-
-
Sebastian Dröge authored
Probes were remembering a cookie that was used to check if the probe was already called this time before the probes list changed. However the same probes could've been called by another thread in between and thus gotten a new cookie, and would then be called a second time. https://bugzilla.gnome.org/show_bug.cgi?id=795987
-
- May 08, 2018
-
-
strncpy() is assumed to be for strings so the compiler assumes that it will need an extra byte for the string-terminaning NULL. For cases where we know it's actually "binary" data, just copy it with memcpy. Fixes compiler warnings with gcc 8. https://bugzilla.gnome.org/show_bug.cgi?id=795756
-
- May 05, 2018
-
-
Tim-Philipp Müller authored
gst_buffer_list_new_sized(0) will cause an underflow in a calculation which then makes it try to allocate huge amounts of memory, which may lead to aborts. https://bugzilla.gnome.org/show_bug.cgi?id=795758
-
-
- May 04, 2018
-
-
- Apr 23, 2018
-
-
Tim-Philipp Müller authored
cc.compiles() doesn't have a 'prefix' argument (yet) and the prefix has already been prepended to the source code snippets. https://github.com/mesonbuild/meson/issues/2364
-
Tim-Philipp Müller authored
-
- Apr 16, 2018
-
-
Mostly related to out parameters and their transfer
-
-
- Apr 11, 2018
-
-
Tim-Philipp Müller authored
When outputting debug logs on Windows, some sections are protected with a non-recursive lock. Turns out though that gst_debug_message_get() might indirectly, via our printf format extensions, call code which in turn would try to log something when it can't handle something. If that happens we end up in gst_debug_log_default() again recursively and try to again take the lock that's already taken, thus deadlocking. Format the debug message string outside of the critical section instead to avoid this. https://bugzilla.gnome.org/show_bug.cgi?id=784382
-
Tim-Philipp Müller authored
-
- Apr 05, 2018
-
-
Remove unneeded reapplication of patterns. Besides being superfluous (gst_debug_reset_threshold already applies patterns) it was also wrong and didn't stop checking patterns after the first match (broken in 67e9d139). Also fix up unit test which checked for the wrong order. https://bugzilla.gnome.org/show_bug.cgi?id=794717
-