- 13 Aug, 2016 1 commit
-
-
Tim-Philipp Müller authored
It's been internal API only in 1.x.
-
- 12 Aug, 2016 1 commit
-
-
Edward Hervey authored
In ringbuffer mode we need to make sure we post buffering messages *before* blocking to wait for data to be drained. Without this, we would end up in situations like this: * pipeline is pre-rolling * Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread is blocking downstream (i.e. not pulling from upstream/queue2). * Therefore pipeline has pre-rolled ... * ... but queue2 hasn't filled up yet, therefore the application waits for the buffering 100% messages before setting the pipeline to PLAYING * But queue2 can't post that message, since the 100% message will be posted *after* there is room available for that last buffer. https://bugzilla.gnome.org/show_bug.cgi?id=769802
-
- 08 Aug, 2016 1 commit
-
-
Josep Torra authored
Remove an unneeded call to g_thread_self and minor coding style fix.
-
- 25 Jul, 2016 4 commits
-
-
Jan Schmidt authored
Handle the new stream-group-done message to unblock pads which are waiting for the running time to advance on that group. https://bugzilla.gnome.org/show_bug.cgi?id=768995
-
Jan Schmidt authored
A new event which precedes EOS in situations where we need downstream to unblock any pads waiting on a stream before we can send EOS. E.g, decodebin draining a chain so it can switch pads. https://bugzilla.gnome.org/show_bug.cgi?id=768995
-
Carlos Rafael Giani authored
Redirection messages are already used in fragmented sources and in uridecodebin, so it makes sense to introduce these as an official message type. https://bugzilla.gnome.org/show_bug.cgi?id=631673
-
Jan Schmidt authored
Other pads that are waiting for the stream on the selected pad to advance before they finish waiting themselves should be given the chance to do so when the selected pad goes EOS. Fixes problems where input streams can end up waiting forever if the active stream goes EOS earlier than their own end time.
-
- 24 Jul, 2016 1 commit
-
-
Tim-Philipp Müller authored
In some corner cases, the error 'code' part passed to GST_ELEMENT_ERROR() is a valid define as well, in which case it won't survive two levels of macro expansion, but only one. Fixes: oss4-sink.c: In function ‘gst_oss4_sink_open’: error: ‘GST_RESOURCE_ERROR_0x00000002’ undeclared (first use in this function) GST_ ## domain ## _ERROR_ ## code, __txt, __dbg, __FILE__, which is from GST_ELEMENT_ERROR(el,RESOURCE,OPEN_WRITE,..) and OPEN_WRITE happens to be defined to 2 here. https://bugzilla.gnome.org/show_bug.cgi?id=756806 https://bugzilla.gnome.org/show_bug.cgi?id=769117
-
- 22 Jul, 2016 5 commits
-
-
Tim-Philipp Müller authored
-
Vincent Penquerc'h authored
-
Vincent Penquerc'h authored
-
Vincent Penquerc'h authored
I had not updated it after the review changes
-
-
- 20 Jul, 2016 2 commits
-
-
Guillaume Desmottes authored
This allow us to filter using an object type which is implemented by a plugin like, say, GstGtkGLSink. https://bugzilla.gnome.org/show_bug.cgi?id=768989
-
-
- 19 Jul, 2016 1 commit
-
-
Jan Schmidt authored
Instead of looping, use the gst_clock_wait_for_sync() function to give clocks up to 1 second to synchronise
-
- 15 Jul, 2016 3 commits
-
-
Guillaume Desmottes authored
gst_structure_id_get() returns a new reference so the returned object is actually (transfer full). The unit tests was already unreffing the objects. https://bugzilla.gnome.org/show_bug.cgi?id=768776
-
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
-