GitLab

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

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

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

running timestamps are guaranteed to be positive and valid since the
GstVideoEncoder base class will clip incoming buffers

CID #1139797

Coverity 1139944

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

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

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

This lets oggdemux determine they are not delta units, and removes
spurious per packet warnings about being unable to determine the
packet's keyframeness.

CID #1212136

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

https://bugzilla.gnome.org/show_bug.cgi?id=730874

Tests that pushing a buffer after the segment returns EOS

It was always returning _OK regardless of what downstream returned

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

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

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

This is more natural and better-suited for a playback application.

From 211fa5f to 1f5d3c3

libs/video.c:540:50: error: comparison of constant 2 with boolean expression is always false
      [-Werror,-Wtautological-constant-out-of-range-compare]
            && !GST_VIDEO_INFO_N_PLANES (&vinfo) > 2) {
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~

Comment in the docs what the client_port and server_port fields are used
for in TCP mode (if the application wants to set those values).

With lots of shared memory instances (e.g. created by a RTP payloader) the
overhead of duplicating the file descriptor and creating extra mappings is
significant. To avoid this, the parent memory maps the whole region and the
shared copies just reuse the same mapping.

https://bugzilla.gnome.org/show_bug.cgi?id=730441

Add a read source on write socket when lost tunnel.
To be able to detect when clint closes get channel.

This is already done in gst_rtsp_source_dispatch_write but
only when the queue is empty.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730368

Otherwise we might end up inside the callback without having stored
the probe id... then try to remove that probe (not!) from the callback
and wait forever for the pad to unblock.

The error we get is a negated errno.

While there, fix a couple typos in messages.