- 15 Jul, 2016 2 commits
-
-
Guillaume Desmottes authored
gst_structure_id_get() returns a new reference so the returned device is actually (transfer full). The code using this API was already correct but the code example in comments was not. https://bugzilla.gnome.org/show_bug.cgi?id=768776
-
Guillaume Desmottes authored
For clarity. https://bugzilla.gnome.org/show_bug.cgi?id=768810
-
- 12 Jul, 2016 1 commit
-
-
Sebastian Dröge authored
If segment.stop was given, and the subclass provides a size that might be smaller than segment.stop and also smaller than the actual size, we would already stop there. Instead try reading up to segment.stop, the goal is to ignore the (possibly inaccurate) size the subclass gives and finish until segment.stop or when the subclass tells us to stop.
-
- 11 Jul, 2016 4 commits
-
-
Stefan Sauer authored
From f363b32 to f49c55e
-
Nirbheek Chauhan authored
flavour_str is a non-const pointer that will be written to if the -f option is passed
-
Guillaume Desmottes authored
-
Edward Hervey authored
When dealing with small-ish input data coming into queue2, such as adaptivedemux fragments, we would never take into account the last <200ms of data coming in. The problem is that usually on TCP connection the download rate gradually increases (i.e. the rate is lower at the beginning of a download than it is later on). Combined with small download time (less than a second) we would end up with a computed average input rate which was sometimes up to 30-50% off from the *actual* average input rate for that fragment. In order to fix this, force the average input rate calculation when we receive an EOS so that we take into account that final window of data. https://bugzilla.gnome.org/show_bug.cgi?id=768649
-
- 08 Jul, 2016 9 commits
-
-
Guillaume Desmottes authored
That's generally the most useful information to help debugging the problem. https://bugzilla.gnome.org/show_bug.cgi?id=768579
-
Guillaume Desmottes authored
Makes debugging easier. https://bugzilla.gnome.org/show_bug.cgi?id=768579
-
Tim-Philipp Müller authored
We don't free this from gst_deinit() but from gst_task_cleanup_all(), so more GStreamer API may be called. In particular makes unit tests work again with CK_FORK=no. https://bugzilla.gnome.org/show_bug.cgi?id=768577
-
Guillaume Desmottes authored
This should not happen and generally means some thread is still running. https://bugzilla.gnome.org/show_bug.cgi?id=768578
-
Guillaume Desmottes authored
This ensures that all async operations (started from gst_element_call_async()) have been completed and so there is no extra thread running. Fix races when checking for leaks on unit tests as some of those operations were still running when the leaks tracer was checking for leaked objects. https://bugzilla.gnome.org/show_bug.cgi?id=768577
-
Guillaume Desmottes authored
Checking for signal.h is not good enough as it's present in Windows. Those signals are UNIX specific anyway. https://bugzilla.gnome.org/show_bug.cgi?id=767857
-
Guillaume Desmottes authored
This allow us to provide the trace of leaked objects making it easier to debug. https://bugzilla.gnome.org/show_bug.cgi?id=767862
-
-
Guillaume Desmottes authored
We don't want to automatically catch signals so use an env variable to enable this feature. https://bugzilla.gnome.org/show_bug.cgi?id=767857
-
- 07 Jul, 2016 2 commits
-
-
Sebastian Dröge authored
That is, if the active pad changed and if forwarding of sticky events is requested at all. We otherwise forward events too often.
-
-
- 06 Jul, 2016 4 commits
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- 05 Jul, 2016 1 commit
-
-
Jan Alexander Steffens 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
-
- 04 Jul, 2016 1 commit
-
-
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
-
- 01 Jul, 2016 2 commits
-
-
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
-
- 30 Jun, 2016 4 commits
-
-
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
-
- 29 Jun, 2016 8 commits
-
-
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
-
- 28 Jun, 2016 1 commit
-
-
Guillaume Desmottes authored
Needed so GstBus can be tracked by the leaks tracer. https://bugzilla.gnome.org/show_bug.cgi?id=768141
-
- 24 Jun, 2016 1 commit
-
-
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
-