- Dec 14, 2015
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Dec 10, 2015
- Dec 07, 2015
-
-
My previous fix for #758029 wasn't quite right and simply made the race rarer. Some of the files are installed by install-exec and others by install-exec, so the hooks need to be split too. https://bugzilla.gnome.org/show_bug.cgi?id=758029
-
- Dec 04, 2015
-
-
Nicolas Dufresne authored
In case of a run-time error message, the process return value was left unset. This would lead to error not being caught at shell level. https://bugzilla.gnome.org/show_bug.cgi?id=759019
-
- Nov 30, 2015
-
-
Thibault Saunier authored
As the names clash with gst_object_get_value[_array] https://bugzilla.gnome.org/show_bug.cgi?id=756950
-
- Nov 19, 2015
-
-
Thiago Santos authored
This reverts commit 2c475a03. This causes issues with h264parse. It breaks timestamps as there are headers in the middle of the stream and this patch makes the timestamps for those differ from the ones that are adjusted, creating a discontinuity and leading to sync issues.
-
Thiago Santos authored
This reverts commit 92181640.
-
- Nov 18, 2015
-
-
Tim-Philipp Müller authored
Downgrade from g_warning to GST_WARNING log message. https://bugzilla.gnome.org/show_bug.cgi?id=758276
-
We're not really interested in our own packets and ignore them anyway.
-
- Nov 16, 2015
-
-
Thiago Santos authored
Avoid repeated checks for testing if a buffer is a header
-
Thiago Santos authored
Otherwise the buffer was left with the original values and later would be compared with other buffers that were converted to runninn time, leading to bad interleaving of multiple streams. https://bugzilla.gnome.org/show_bug.cgi?id=757961
-
Thiago Santos authored
baseparse tries to preserve timestamps from upstream if it is running on a time segment and write that to output buffers. It assumes the first DTS is going to be segment.start and sets that to the first buffers. In case the buffer is a header buffer, it had no timestamps and will have only the DTS set due to this mechanism. This patch prevents this by skipping this behavior for header buffers. https://bugzilla.gnome.org/show_bug.cgi?id=757961
-
The install hook needs to be a install-data-hook not an install-exec-hook as the helpers are installed into helperdir which is considered data (only path variables with "exec" in are considered executables). The explicit dependency on install-helpersPROGRAMS was an attempt at solving this, but this causes occasional races where install-helpersPROGRAMS can run twice in parallel (once via install-all, once via the hook's dependency). https://bugzilla.gnome.org/show_bug.cgi?id=758029
-
- Nov 07, 2015
-
-
Instead of re-sending sticky events over and over to a not-linked pad, mark them as sent the first time. If the not-linked came from downstream, it already received the events. If the pad is actually not-linked, the sticky events will be rescheduled when the pad is linked anyway.
-
Allow deactivation in pull-mode, since that implies we had a peer, activated in pull mode, then the peer disa-peer-ed ;)
-
- Oct 30, 2015
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Oct 29, 2015
-
-
Sebastian Dröge authored
Without this, flushing might not unblock the streaming thread and cause deadlocks. https://bugzilla.gnome.org/show_bug.cgi?id=757257
-
- Oct 27, 2015
-
-
Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative. Pasting from design docs: =============================== Stream time is calculated using the buffer times and the preceding SEGMENT event as follows: stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time For negative rates, B.timestamp will go backwards from S.stop to S.start, making the stream time go backwards. =============================== Therefore, the calculation for applied_rate < 0 should be: stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time and the reverse: B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate) https://bugzilla.gnome.org/show_bug.cgi?id=756810
-
Renamed the "result" variable to "stream_time" for better readability.
- Oct 21, 2015
-
-
Sebastian Dröge authored
It's not get_bufferlist(). Because of that it was ignored by the docs and G-I, leading to crashes because of broken ownership transfer. https://bugzilla.gnome.org/show_bug.cgi?id=756898
-
- Oct 20, 2015
-
-
Sebastian Dröge authored
An ASYNC READY->PAUSED might have failed without the bin code noticing during the state change, in which case we will never get PAUSED->READY and would leak messages. https://bugzilla.gnome.org/show_bug.cgi?id=756611
-
- Oct 19, 2015
-
-
Previously this code was just blindly setting the cached flow return of downstream to GST_FLOW_OK when we get a SEGMENT. The problem is that this can not be done blindly. If downstream was not linked, the corresponding sinqlequeue source pad thread might be waiting for the next ID to be woken up upon. By blindly setting the cached return value to GST_FLOW_OK, and if that stream was the only one that was NOT_LINKED, then the next time we check (from any other thread) to see if we need to wake up a source pad thread ... we won't even try, because none of the cached flow return are equal to GST_FLOW_NOT_LINKED. This would result in that thread never being woken up https://bugzilla.gnome.org/show_bug.cgi?id=756645
-
- Oct 13, 2015
-
-
Our current position has nothing to do with being linked or not. Avoids having stray segment updates fired every 2s
-
- Oct 07, 2015
-
-
The previous change (see bgo #756069) was causing us to free the same pointer multiple times. If we actually get a sample back, the test fails, no need to free anything in that case.
-
When sample is got using gst_tag_list_get_sample_index, it should be free'd. https://bugzilla.gnome.org/show_bug.cgi?id=756069
-
Sebastian Dröge authored
In file included from gst-ptp-helper.c:40:0: /usr/include/net/if.h:265:19: error: field 'ifru_addr' has incomplete type struct sockaddr ifru_addr; https://bugzilla.gnome.org/show_bug.cgi?id=756136
-
- Sep 29, 2015
-
-
Tim-Philipp Müller authored
Broke this when I removed the G_GNUC_PRINTF in a previous commit to fix indentation, since it was not really needed. Turns out unlike gcc clang warns though if a non-literal format string is passed then. Fix indentation differently. http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
-
- Sep 25, 2015
-
-
Sebastian Dröge authored
-