- Jun 22, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jun 20, 2014
-
-
Sebastian Dröge authored
With most decoder libraries, and especially when accessing codecs via OpenMAX or similar APIs, we don't have the ability to properly related the output buffers to a number of input samples. And could e.g. get a fractional number of input buffers decoded at a time. Previously this would in the end lead to an error message and stopped playback. Change it to a warning message instead and try to handle it gracefully. In theory the subclass can now get timestamp tracking wrong if it completely misuses the API, but if on average it behaves correct (and gst-omx and others do) it will continue to work properly. Also add a test for the new behaviour. We don't change it in the encoder yet as that requires more internal logic changes AFAIU and I'm not aware of a case where this was a problem so far.
-
- Jun 13, 2014
-
-
g_socket_accept() is only called once for a server socket. So keeping the socket open ist just confusing possible clients. https://bugzilla.gnome.org/show_bug.cgi?id=731566
-
-
Canceling the accept/select happens when the source is shut down. This is not an error and the GST_FLOW_ERROR causes problems when only part of the pipeline is shut down. https://bugzilla.gnome.org/show_bug.cgi?id=731567
-
- Jun 12, 2014
-
-
Edward Hervey authored
We are scaling from a unit in microseconds to a unit in ((1 << 32) per seconds). We therefore scale the microseconds values by: value of a second in the target unit (1 << 32) -------------------------------------------------------------- value of a second in the origin format (1 000 000 microsecond)
-
- Jun 11, 2014
-
-
Vincent Penquerc'h authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Jun 10, 2014
-
-
Thiago Santos authored
Adds a send_event handling for allowing appsrc to flush its internal data, allowing users to flush the pipeline without setting it to null. https://bugzilla.gnome.org/show_bug.cgi?id=724231
-
Thiago Santos authored
The strides that are set from the GstVideoInfo structs are a gsize. Using an int can cause overflows when dealing with large enough images https://bugzilla.gnome.org/show_bug.cgi?id=731195
-
Thiago Santos authored
size is a gsize, so cast the operands to it to avoid overflows and setting wrong value to the video size. Includes tests. https://bugzilla.gnome.org/show_bug.cgi?id=731195
-
- Jun 09, 2014
-
-
Edward Hervey authored
running timestamps are guaranteed to be positive and valid since the GstVideoEncoder base class will clip incoming buffers CID #1139797
-
Edward Hervey authored
Coverity 1139944
-
- Jun 06, 2014
-
-
Vincent Penquerc'h authored
-
- Jun 05, 2014
-
-
Sebastian Dröge authored
-
- Jun 04, 2014
-
-
Sebastian Dröge authored
When playing RTSP streams there will be one decodebin per stream. If some of them fail because of a missing plugin we should not fail completely but play the supported streams at least. https://bugzilla.gnome.org/show_bug.cgi?id=730868
-
Sebastian Dröge authored
-
A simple '&' is not sufficiant. With mmapping_flags == PROT_READ and prot == PROT_READ|PROT_WRITE the check produces the wrong result. Change the check to make sure that prot is a subset of mmapping_flags. https://bugzilla.gnome.org/show_bug.cgi?id=730559
-
- Jun 03, 2014
-
-
Vincent Penquerc'h authored
-
Vincent Penquerc'h authored
When a pipeline using alsasink and push mode upstream fails to preroll, the following state will be the case: - A loop upstream will be PAUSED, pushing a first buffer - alsasink will be READY, pending PAUSED, because async On error, the pipeline will switch to NULL. alsasink is in READY, so goes to NULL immediately. It zeroes its cached caps. Meanwhile, the upstream loop can cause a caps query, conccurent with the state change. This will use those cached caps. If the zeroing happens between the NULL test and the dereferencing, GStreamer will critical down in the GstValue code. Since it appears that such a gap between states (PAUSED and pushing upstream, and NULL downstream) is expected, we need to protect the read/write access to the cached caps. This fixes the critical. See https://bugzilla.gnome.org/show_bug.cgi?id=731121
-
Only EOS and segment should be deleted in that case. + Add a testcase https://bugzilla.gnome.org/show_bug.cgi?id=709868
-
Only EOS and segment should be deleted in that case. https://bugzilla.gnome.org/show_bug.cgi?id=709868
-
Only EOS and segment should be deleted in that case. https://bugzilla.gnome.org/show_bug.cgi?id=709868
-
Only EOS and segment should be deleted in that case. https://bugzilla.gnome.org/show_bug.cgi?id=709868
-
Only EOS and segment should be deleted in that case. https://bugzilla.gnome.org/show_bug.cgi?id=709868
-
- Jun 02, 2014
-
-
Vincent Penquerc'h authored
This lets oggdemux determine they are not delta units, and removes spurious per packet warnings about being unable to determine the packet's keyframeness.
-
Edward Hervey authored
CID #1212136
-
- May 29, 2014
-
-
Thiago Santos authored
Aggregate buffering messages to only post the lower value to avoid setting pipeline to playing while any multiqueue is still buffering. There are 3 scenarios where the entries should be removed from the list: 1) When decodebin is set to READY 2) When an element posts a 100% buffering (already implemented) 3) When a multiqueue is removed from decodebin. For item 3 we don't need to handle it because this should only happen when either 1 is hapenning or when it is playing a chained file, for which number 2 should have happened for the previous stream to finish https://bugzilla.gnome.org/show_bug.cgi?id=726423
-
- May 28, 2014
- May 27, 2014
-
-
Thiago Santos authored
Tests that pushing a buffer after the segment returns EOS
-
Thiago Santos authored
It was always returning _OK regardless of what downstream returned
-
- May 26, 2014
-
-
Thiago Santos authored
if a buffer is clipped by being completely out of segment, check if this buffer is after the end of the segment and return EOS upstream https://bugzilla.gnome.org/show_bug.cgi?id=709224
-
Thiago Santos authored
if a buffer is clipped by being completely out of segment, check if this buffer is after the end of the segment and return EOS upstream https://bugzilla.gnome.org/show_bug.cgi?id=709224
-
Thiago Santos authored
Fixes the handling of GST_FLOW_EOS by using the helper object from gstutils that does the correct combination of flow returns. https://bugzilla.gnome.org/show_bug.cgi?id=709224
-
- May 23, 2014
-
-
Tim-Philipp Müller authored
This is more natural and better-suited for a playback application.
-
- May 21, 2014
-
-
Sebastian Dröge authored
-