- Jul 06, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jul 05, 2016
-
-
Jan Alexander Steffens (heftig) authored
Waiting before posting calculated bitrates seems to be the intent of the code, so avoid adding them to the tag list pushed with the first frame. When the threshold is reached, gst_base_parse_update_bitrates sets tags_changed, so this posts the calculated ones right that moment. This prevents an insane average calculated from just the first (key) frame from getting posted. https://bugzilla.gnome.org/show_bug.cgi?id=768439
-
- Jul 04, 2016
-
-
Sebastian Dröge authored
baseparse: Make sure to not create an invalid event order when generating the default CAPS event because of a GAP event There must be a SEGMENT event before the GAP event, and SEGMENT events must come after any CAPS event. We however did not produce any CAPS yet, so we need to ensure to insert the CAPS event before the SEGMENT event into the pending events list. https://bugzilla.gnome.org/show_bug.cgi?id=766970
-
- Jul 01, 2016
-
-
Jan Schmidt authored
gcc 6 has problems detecting and avoiding throwing a warning for tautological compares in macros (they should only trigger for compares outside macros). Avoid them with a nasty cast of one parameter to void * https://bugzilla.gnome.org/show_bug.cgi?id=764526
-
Edward Hervey authored
This is an update on c9b68488 multiqueue: Fix not-linked pad handling at EOS While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS, it would break the same issue when *downstream* returns GST_FLOW_EOS (which can happen for example when downstream decoders receive data from after the segment stop). GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it and not when a GST_EVENT_EOS has gone through it. In order to handle both cases, also take into account the last flow return. https://bugzilla.gnome.org/show_bug.cgi?id=763770
-
- Jun 30, 2016
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Edward Hervey authored
When syncing by running time, multiqueue will throttle unlinked streams based on a global "high-time" and the pending "next_time" of a stream. The idea is that we don't want unlinked streams to be "behind" the global running time of linked streams, so that if/when they get linked (like when switching tracks) decoding/playback can resume from the same position as the other streams. The problem is that it assumes elements downstream will have a more or less equal buffering/latency ... which isn't the case for streams of different type. Video decoders tend to have higher latency (and therefore consume more from upstream to output a given decoded frame) compared to audio ones, resulting in the computed "high_time" being at the position of the video stream, much further than the audio streams. This means the unlinked audio streams end up being quite a bit after the linked audio streams, resulting in gaps when switching streams. In order to mitigate this issue, this patch adds a new "group-id" pad property which allows users to "group" streams together. Calculating the high-time will now be done not only globally, but also per group. This ensures that within a given group unlinked streams will be throttled by that group's high-time instead. This fixes gaps when switching downstream elements (like switching audio tracks).
-
Edward Hervey authored
* GstStream * GstStreamCollection * GST_EVENT_SELECT_STREAMS * GST_MESSAGE_STREAM_COLLECTION
-
- Jun 29, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
Especially if multiple threads are waiting for buffers to be available again, the current code was wrong. Fix this and document clearly how the GstPoll is supposed to be used. Also fix some potential races with reading from the GstPoll before writing actually happened. https://bugzilla.gnome.org/show_bug.cgi?id=767979
-
Sebastian Dröge authored
It might happen that we popped the message before writing of the control happened. In this case we just have to retry again a bit later, and failure to do so will cause an additional byte in the control and the GSource / gst_poll_wait() to always wake up again immediately. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
Sebastian Dröge authored
Also just read/write control every time, GstPoll is optimized by itself already to only do I/O if switching between empty and one byte. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
Sebastian Dröge authored
And also mention what the expected values of errno are going to be. write_control() will only ever return FALSE if there was a critical error. It will never return because of EINTR, EAGAIN or EWOULDBLOCK. read_control() will return FALSE if there was no byte to read, in which case errno would be EWOULDBLOCK. In all other cases there was a critical error. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
Sebastian Dröge authored
On timer GstPolls it will cause the control socket state to become inconsistent as now one less read_control() than write_control() be would needed. Similarly, read_control() and write_control() are only valid on timer GstPolls. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
Sebastian Dröge authored
This might fail even under correct usage, e.g. if read_control() is called from another thread before write_control() finished in another. It has to be retried then, or other measures have to be taken, depending on how it is used by the surrounding code. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
Matthew Gruenke authored
This addresses slightly different race conditions on Linux and Windows, and fixes gst_poll_read_control() when control_pending == 0. On Linux, the socketpair() used for control should not be made O_NONBLOCK. If there's any propagation delay between set->control_write_fd.fd and set->control_read_fd.fd, even the mutex now held will not be sufficient to prevent a race condition. There's no benefit to using O_NONBLOCK, here. Only liabilities. For Windows, it's necessary to fix the race condition between testing set->control_pending and performing WAKE_EVENT()/RELEASE_EVENT(). This is accomplished by acquiring and holding set->lock, for both of these operations. We could optimize the Linux version by making this Windows-specific. For consistency with the Linux implementation, Windows' RELEASE_EVENT() has also been made to block, although it should never happen. Also, changed release_wakeup() to return TRUE and decrement control_pending only when > 0. Furthermore, RELEASE_EVENT() is called only when control_pending == 1. Finally, changed control_pending to use normal, non-atomic arithmetic operations, since it's now protected by set->lock. Note: even though the underlying signaling mechanisms are blocking, release_wakeup() is effectively non-blocking, as it will only attempt to read from control_read_fd.fd after a byte has been written to control_write_fd.fd or WaitForSingleObject() after it's been signaled. https://bugzilla.gnome.org/show_bug.cgi?id=750397
-
- Jun 28, 2016
-
-
Guillaume Desmottes authored
Needed so GstBus can be tracked by the leaks tracer. https://bugzilla.gnome.org/show_bug.cgi?id=768141
-
- Jun 24, 2016
-
-
Nirbheek Chauhan authored
GCC emits an error for this with -Werror: plugin.c:22:1: error: 'gst_plugin_desc' initialized and declared 'extern' [-Werror] This matches how glib does symbol exporting. https://bugzilla.gnome.org/show_bug.cgi?id=767463
-
- Jun 23, 2016
-
-
Nirbheek Chauhan authored
If the prototypes in the public API have dllimport in them when building statically on Windows, the compiler will look for symbols with symbol mangling and indirection corresponding to a DLL. This will cause a build failure when trying to link tests/examples/etc. External users of GStreamer also need to define -DGST_STATIC_COMPILATION if they want to link to static gstreamer libraries on Windows. A similar version of this patch has been committed to all gstreamer repositories. https://bugzilla.gnome.org/show_bug.cgi?id=767463
-
- Jun 21, 2016
-
-
Nicolas Dufresne authored
From ac2f647 to f363b32
-
-
Vincent Penquerc'h authored
Ensure we do not attempt to destroy the current range. Doing so causes the current one to be left dangling, and it may be dereferenced later, leading to a crash. This can happen with a very small queue2 ring buffer (10000 bytes) and 4 kB buffers. repro case: gst-launch-1.0 fakesrc sizetype=2 sizemax=4096 ! \ queue2 ring-buffer-max-size=1000 ! fakesink sync=true https://bugzilla.gnome.org/show_bug.cgi?id=767688
-
- Jun 20, 2016
-
-
Tim-Philipp Müller authored
-
- Jun 17, 2016
-
-
Reynaldo H. Verdejo Pinochet authored
-
Nicolas Dufresne authored
This patch handle the case when you have 1 pad (so the fast path is being used) but this pad is removed. If we are in allow-not-linked, we should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED and ignore the meaningless return value obtained from pushing. https://bugzilla.gnome.org/show_bug.cgi?id=767413
-
- Jun 16, 2016
-
-
Stefan Sauer authored
The script extracts cpu-usage data from a tracelog and plots it via gnuplot.
-
- Jun 15, 2016
-
-
Sebastian Dröge authored
paramater -> parameter
-
- Jun 14, 2016
-
-
Tim-Philipp Müller authored
-
- Jun 13, 2016
-
-
Sebastian Dröge authored
If we were in PAUSED, the current clock time and base time don't have much to do with the running time anymore as the clock might have advanced while we were PAUSED. The system clock does that for example, audio clocks often don't. Updating the start time in PAUSED will cause a) the wrong position to be reported, b) step events to step not just the requested amount but the amount of time we spent in PAUSED. The start time should only ever be updated when going from PLAYING to PAUSED to remember the current running time (to be able to compensate later when going to PLAYING for the clock time advancing while PAUSED), not when we are already in PAUSED. Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com> The updating of the start time when the state is lost was added in commit ba943a82 to fix the position reporting when the state is lost. This still works correctly after this change. https://bugzilla.gnome.org/show_bug.cgi?id=739289
-
- Jun 11, 2016
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
pad: Also check the number of segment events and if other serialized events and queries trigger segment updating too https://bugzilla.gnome.org/show_bug.cgi?id=765049
-
-
- Jun 10, 2016
-
-
Sebastian Dröge authored
We don't do calculations with different units (buffer offsets and bytes) anymore but have functions for: 1) getting the number of bytes since the last discont 2) getting the offset (and pts/dts) at the last discont and the previously added function to get the last offset and its distance from the current adapter position. https://bugzilla.gnome.org/show_bug.cgi?id=766647
-
Edward Hervey authored
API: gst_buffer_prev_offset API: gst_buffer_get_offset_from_discont The gst_buffer_get_offset_from_discont() method allows retrieving the current offset based on the GST_BUFFER_OFFSET of the buffers that were pushed in. The offset will be set initially by the GST_BUFFER_OFFSET of DISCONT buffers, and then incremented by the sizes of the following buffers. The gst_buffer_prev_offset() method allows retrievent the previous GST_BUFFER_OFFSET regardless of flags. It works in the same way as the other gst_buffer_prev_*() methods. https://bugzilla.gnome.org/show_bug.cgi?id=766647
-
- Jun 09, 2016
-
-
Tim-Philipp Müller authored
-
- Jun 08, 2016
-
-
Sebastian Dröge authored
We already had a _full() version, but having that alone seems inconsistent. Add a non-full version that mirrors the behaviour of gst_pad_link() vs gst_pad_link_full().
-
- Jun 07, 2016
-
-
Edward Hervey authored
If we drop a frame that contained a discontinuity, we must remember that for the next frame that *will* be pushed downstream. https://bugzilla.gnome.org/show_bug.cgi?id=766795
-