- Jun 28, 2014
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jun 27, 2014
-
-
Thiago Santos authored
Let go the reference to the converter caps after using it
-
Tim-Philipp Müller authored
Just shows devices with basic info and exits. Or will wait for more devices to show up or be removed with the --follow option. It's also possible to pass filters as command line arguments in the form DEVICE_CLASSES or DEVICE_CLASSES:CAPS.
-
- Jun 26, 2014
-
-
Sebastian Dröge authored
Remove the macros that used them, nobody could've used them anyway.
-
Gwenole Beauchesne authored
Recognize H.264 Level 5.2, as exposed by modern 2160p30+ streams, i.e. commonly known as 4K. Also add initial support for handling Annex.G (SVC) profiles. https://bugzilla.gnome.org/show_bug.cgi?id=732269 Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
-
Jan Schmidt authored
Fixes a problem with at least one file being detected incorrectly as DTS because there's DTS packets early enough in the file.
-
- Jun 23, 2014
-
-
Tim-Philipp Müller authored
Makes it pass on 32-bit systems.
-
- Jun 22, 2014
-
-
Tim-Philipp Müller authored
Makes it pass on 32-bit systems.
-
Sebastian Dröge authored
We can't convert to ANY capsfeatures, they are only there so that we can passthrough whatever downstream can support... but we definitely don't want to return them to upstream.
-
Sebastian Dröge authored
-
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
-