Age | Commit message (Collapse) | Author | Files | Lines |
|
https://bugzilla.gnome.org/show_bug.cgi?id=744572
API: gst_flow_combiner_update_pad_flow()
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=744572
API: gst_flow_combiner_reset()
|
|
|
|
|
|
Instead of always shortening the __FILE__ path, even if the
log message is not actually printed, which might happen if
the log level is activated but the category is not, only
shorten the path if we're actually going to output it and
if it looks like it needs shortening. Log handlers had no
guarantee that they would get a name instead of a path
anyway on any architecture, so it shouldn't be a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=745213
|
|
This is useful not only for MSVC, but also with gcc/Linux
when doing cross-compilation builds and out-of-tree builds.
https://bugzilla.gnome.org/show_bug.cgi?id=745213
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=744338
|
|
This is a leftover from 0.10 and not needed anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=745210
|
|
It might still be waiting for a query to be handled, or the queue to become
empty again for the next item. Also if downstream returns FLUSHING, flush the
queue like we do in queue and multiqueue.
|
|
Otherwise we might wait forever for serialized queries to be handled as the
loop function is stopped and as such we will never ever dequeue the query and
handle it.
https://bugzilla.gnome.org/show_bug.cgi?id=745319
|
|
This comes up quite a lot and it's a common mistake, so let's
try to improve the warning message a little.
|
|
The default latency query handler now implements this logic
|
|
|
|
A single unlinked pad can make the latency query fail across the
pipeline, which is probably not desirable. Instead, we return a default
anything goes value.
Perhaps we should also be emitting a gst_message_new_latency() when a
PLAYING element has one of its pads linked.
https://bugzilla.gnome.org/show_bug.cgi?id=745197
|
|
If we saw GAP events (meaning the streams is advancing) before we get
EOS, we should not post an ERROR, since it is not fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=745143
|
|
Some systems will crash if we use non-printable characters in print/debug
statements.
Make sure that GST_FOURCC_ARGS never does that
https://bugzilla.gnome.org/show_bug.cgi?id=745144
|
|
If the checks were changed to using g_return_if_fail() the GST_DEBUG lines
about the specific failure would be lost.
|
|
gst_pad_link_filtered() is very long gone and current
gst_element_link_pads_filtered() doesn't apply to this Fixme comment.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=745122
|
|
Remove dead link to wiki page for SubmittingPatches
https://bugzilla.gnome.org/show_bug.cgi?id=730311
|
|
By applying the supplied transformation to the program name,
for example --program-prefix.
|
|
Otherwise doing "make install DESTDIR" will try to write to
/usr/share/...
|
|
|
|
current upstream segment
|
|
|
|
|
|
|
|
Fixes the build on Windows
(https://ci.gstreamer.net/job/cerbero-cross-mingw32/1742/console)
|
|
Disable bash completion during distchecking otherwise
it may try to install into a system path and fail.
|
|
Fixes 'make dist'
|
|
+ Gets installed
+ Uses a helper tool, gst-completion-helper, installed in
bash-completions/helpers.
+ Adds a common script that other tools can source.
https://bugzilla.gnome.org/show_bug.cgi?id=744877
|
|
|
|
This reverts commit 1911554cff2c4a11772b541a8215a80c728b1097.
This breaks the functionality of GST_PAD_FLAG_NEED_PARENT, the reason for this
flag is that if a pad is removed from a running element, you don't want
functions (such as chain or event) to be called on the pad without a parent set.
This can happen if you remove a request or sometimes pad from a running element.
I don't see the code that caused this in tsdemux, but if it needs to unset
the flag on remove, it should do it itself and then make sure that the parent
exists in any pad function.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=744777
|
|
upstream query fails
|
|
|
|
|
|
|
|
|
|
current levels
instead of just assuming one buffer.
|
|
Revive message in dispose handler before we signal the bus thread,
otherwise the bus thread might be woken up and unref the message
before we had a chance to revive it yet.
|
|
|
|
Async message delivery (where the posting thread gets blocked
until the message has been processed and/or freed) was pretty
much completely broken.
For one, don't use GMutex implementation details to check
whether a mutex has been initialized or not, esp. not
implementation details that don't hold true any more with
newer GLib versions where atomic ops and futexes are used
(spotted by Josep Torras). This led to async message
delivery no longer blocking with newer GLib versions on
Linux.
Secondly, after async delivery don't free mutex/GCond
embedded inside the just-freed message structure.
Use a new (private) mini object flag to signal GstMessage
that the message being freed is part of an async delivery
on the bus so that the dispose handler can keep the message
alive and the bus can free it once it's done cleaning up
stuff.
|
|
Print unset offsets as 'none' instead of humongous numbers,
for better readability.
|
|
Otherwise we'll get warnings like this:
cannot initialize GValue with type 'gboolean', the value has already been initialized as 'gboolean'
|
|
If an element implements wrongly the URI query and set the uri to NULL and if
the element calls gst_pad_create_stream_id at some point, it will lead to crash
as the uri is not supposed to be NULL in the gst_pad_create_stream_id_internal
function.
https://bugzilla.gnome.org/show_bug.cgi?id=744520
|
|
And avoid freeing something we do not own
|
|
|
|
Changes docs and message according to latency handling fix
|
|
sscanf() doesn't handle G_GUINT64_FORMAT well on mingw64 it
appears, leading to compiler warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=744034
|