| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=763912
|
|
and also change the description accordingly since function returns an
incremented caps object or NULL if there is no caps set.
https://bugzilla.gnome.org/show_bug.cgi?id=763912
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=763895
|
|
Ensure that not-linked pads will drain out at EOS by
correctly detecting the EOS condition based on the EOS
pad flag (which indicates we actually pushed an EOS),
and make sure that not-linked pads are woken when doing
EOS processing on linked pads.
https://bugzilla.gnome.org/show_bug.cgi?id=763770
|
|
Unlock when returning NULL from gst_single_queue_new(), and don't
crash with debug logging enabled if NULL is returned.
Spotted by Steven Hoving.
|
|
segment.position is meant for internal usage only, but the various
GST_EVENT_SEGMENT creationg/parsing functions won't clear that field.
Use the appropriate segment boundary as an initial value instead
|
|
If an application calls gst_pad_query_caps from its "have-type" signal handler,
then the query fails because typefind->caps has not been set yet.
This patch sets typefind->caps in the object method handler, before the signal
handlers are called.
https://bugzilla.gnome.org/show_bug.cgi?id=763491
|
|
downstream only in the default signal handler
https://bugzilla.gnome.org/show_bug.cgi?id=763491
|
|
Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
afterwards we would push buffers before those tags and a lot of code assumes that
tags are available before preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=763553
|
|
We have no guarantees about what flags are set on buffers we take
out of the GstAdapter. If we push out multiple buffers from the
first input buffer (which will have discont set), only the first
buffer we push out should be flagged as discont, not all of the
buffers produced from that first initial input buffer.
Fixes issue where the first few mp3 frames/seconds of data in push
mode were skipped or garbled in some cases, and the discont flags
would also trip up decoders which were getting drained/flushed for
every buffer. This was a regression introduced in 1.6 apparently.
|
|
In case the property was not interpollable we might never initialize
the GValue, we should thus never unset it.
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=760704
|
|
If no providers for a particular class could be found, then removing unmatched
filters would cause all devices to be returned instead which is not at all what
the user intended. We still return 0 for unmatched filters.
|
|
Error was not released if gst_ntp_packet_receive failed.
https://bugzilla.gnome.org/show_bug.cgi?id=760598
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=755657
|
|
Based on patch by: Aleksander Wabik <awabik@opera.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755971
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=759948
|
|
To make clear caller is responsible to unref them.
https://bugzilla.gnome.org/show_bug.cgi?id=759948
|
|
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=758980
|
|
My previous fix for #758029 wasn't quite right and simply made the race rarer.
Some of the files are installed by install-exec and others by install-exec, so
the hooks need to be split too.
https://bugzilla.gnome.org/show_bug.cgi?id=758029
|
|
In case of a run-time error message, the process return value was left
unset. This would lead to error not being caught at shell level.
https://bugzilla.gnome.org/show_bug.cgi?id=759019
|
|
As the names clash with gst_object_get_value[_array]
https://bugzilla.gnome.org/show_bug.cgi?id=756950
|
|
This reverts commit 2c475a035543efc0202ecdc52070295a421ed4b4.
This causes issues with h264parse. It breaks timestamps as
there are headers in the middle of the stream and this patch
makes the timestamps for those differ from the ones that
are adjusted, creating a discontinuity and leading to sync
issues.
|
|
This reverts commit 921816400bf3ad65f8978a50569a7d87ef05c806.
|
|
Downgrade from g_warning to GST_WARNING log message.
https://bugzilla.gnome.org/show_bug.cgi?id=758276
|
|
We're not really interested in our own packets and ignore them anyway.
|
|
Avoid repeated checks for testing if a buffer is a header
|
|
Otherwise the buffer was left with the original values and later would
be compared with other buffers that were converted to runninn time,
leading to bad interleaving of multiple streams.
https://bugzilla.gnome.org/show_bug.cgi?id=757961
|
|
baseparse tries to preserve timestamps from upstream if
it is running on a time segment and write that to
output buffers. It assumes the first DTS is going to be
segment.start and sets that to the first buffers. In case
the buffer is a header buffer, it had no timestamps and
will have only the DTS set due to this mechanism.
This patch prevents this by skipping this behavior for
header buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=757961
|
|
The install hook needs to be a install-data-hook not an install-exec-hook as the
helpers are installed into helperdir which is considered data (only path
variables with "exec" in are considered executables).
The explicit dependency on install-helpersPROGRAMS was an attempt at solving
this, but this causes occasional races where install-helpersPROGRAMS can run
twice in parallel (once via install-all, once via the hook's dependency).
https://bugzilla.gnome.org/show_bug.cgi?id=758029
|
|
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
|
|
Allow deactivation in pull-mode, since that implies we
had a peer, activated in pull mode, then the peer disa-peer-ed ;)
|
|
|
|
|
|
|
|
Without this, flushing might not unblock the streaming thread and cause deadlocks.
https://bugzilla.gnome.org/show_bug.cgi?id=757257
|
