Running two threads, one executing the timer and one unscheduling it, the
unscheduled status set by the second thread is sometimes overwritten by the
first one.
https://bugzilla.gnome.org/show_bug.cgi?id=737999
These are actually not true.
gsturi.c: In function '_gst_uri_string_to_table.constprop':
gsturi.c:1316:27: error: 'pct_kv_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
for (next_sep = strcasestr (value, pct_kv_sep); next_sep;
^
gsturi.c:1283:24: error: 'pct_part_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
next_sep = strcasestr (next_sep + 1, pct_part_sep)) {
^
We're not actually doing anything differently anywhere when
we detect that we're running under valgrind, so let's not
print that confusing message that makes people wonder how
they can switch it off so they can valgrind the normal
code paths. Seeing that we're not doing that nor have done
so in the last 10 years we might just as well remove the
entire check actually.
I was confused by the existence of `gst_buffer_get_meta` as it suggested
to me that you should only attach one of any type of GstMeta to a buffer.
It's perfectly fine to attach multiple from a single API so I'm
documenting that here.
https://bugzilla.gnome.org/show_bug.cgi?id=737129
Use user_data to pass the log_file handle to the logger-function.
If one wants to change the log target (e.g. GST_DEBUG_FILE), simply call
gst_debug_remove_log_function() and re-add the handler with the new log-target
using gst_debug_add_log_function ().
Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.
On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.
On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735357
Don't rely on g_source_remove() because it operates on the main
context. If a signal watch was added to a new thread-default context
g_source_remove() would have no effect. So simply use
g_source_destroy() to avoid this problem.
Additionally the source_id was removed from GstBusPrivate because it
was redundant with the signal watch GSource also stored in that
structure.
https://bugzilla.gnome.org/show_bug.cgi?id=734716
This function is not really pad or slow for the common case of requesting a
pad with the name of the template. It is only slower if you to name your pads
directly instead of letting the element handle it.
Also there's no reason to deprecate it in favor of a more complicated function
for the common case.
Previously gst_element_link_pads_full() forgot to unreference or release
request pads in several error cases. Also comments were added mentioning
why releasing is not necessary in some places.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=733119
default_alloc_buffer() calls gst_buffer_new_allocate() but does not check for
failed allocation.
This patch makes default_alloc_buffer() return an error (GST_FLOW_ERROR) if
buffer allocation fails.
https://bugzilla.gnome.org/show_bug.cgi?id=733974
SetEvent() seems to not call SetLastError(0) internally, so checking last
error after calling SetEvent() may return the error from an earlier W32 API
call. Fix this by calling SetlastError(0) explicitly.
Currently WAKE_EVENT() code is cramped into a macro and doesn't look to be
entirely correct. Particularly, it does not check the return value of
SetEvent(), only the thread-local W32 error value. It is likely that SetEvent()
actually just returns non-zero value, but the code mistakenly thinks that the
call has failed, because GetLastError() seems to indicate so.
https://bugzilla.gnome.org/show_bug.cgi?id=733805
We can now create and free a buffer list with one slice alloc/free
call in most cases, instead of one slice alloc/free for the list,
one slice alloc/free for the GArray, and one malloc/free for the
GArray array. In practice we know the max size of our buffer list
from the start, so can avoid reallocs.
https://bugzilla.gnome.org/show_bug.cgi?id=732284
When serializing GstStructures from events in GDP it will add a taglist
as a GstStructure field, having the compare function allows comparison of
GstStructures to check if the serialized/deserialized version matches the
original one, among other cases.
https://bugzilla.gnome.org/show_bug.cgi?id=733131
* GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
* Expand GST_MESSAGE_DEVICE to the full enum value names
* Correct the incorrect references to the GstDeviceProvider interfaces
* Describe caps arguments for gstcheck interface
* Add missing docs for GstNetAddressMeta and its add function
* Add docs for toc helper macros
* Avoid refering to GstValueList type as done elsewhere
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732786
GST_MESSAGE_ANY was considered a long by pygobject and gjs, and thus
couldn't be used in gst_bus_poll() and similar APIs as they expect an
int-typed enum.
Just use 0xffffffff instead for now.
https://bugzilla.gnome.org/show_bug.cgi?id=732633
Support for (nullable) was added to G-I at the same time as nullable
return values. Previous versions of G-I will not mark return values as
nullable, even when an (allow-none) annotation is present, so it is
not necessary to add (allow-none) annotations for compatibility with
older versions of G-I.
https://bugzilla.gnome.org/show_bug.cgi?id=730957
Boxed types can't be derived from, and we don't support
deriving from our special fundamental types (the code
checks for GType equality in most places.
Currently we leak the internal representation of them as two GValues that
contain a fraction. Without this we could store fraction ranges as
data[0] = (min_n << 32) | (min_d)
data[1] = (max_n << 32) | (max_d)
and wouldn't require an additional allocation per range.
Otherwise negative values will sets all of the 64 bits due to two's
complement's definition of negative values.
Also add a test for negative int ranges.
Both gst_value_intersect and gst_value_subtract will call
gst_value_compare if one of their arguments isn't a list.
gst_value_compare will then re-do a check to see if one of
the arguments is a list (for the special case of comparing a unitary
value with a list of length 1).
The problem is that the various G_VALUE_HOLDS represent an expensive
amount of calling gst_value_compare (almost half of it) to see if
the provided arguments are list. These checks can be done without
when we know that the arguments aren't lists.
* Create a new "nolist" gst_value_compare which avoids that special
case comparision
Benchmarks:
valgrind/callgrind: average speedup in instruction calls for
gst_value_intersect and gst_value_subtract is around 56% (Makes 63%
of the calls it used to take previously)
tests/benchmarks/capsnego: With default settings (depth 4, children 3
607 elements), time taken for transition from READY to PAUSED:
Before : 00.391519153
After : 00.220397492
56% of the time previously used, +77% speedup
https://bugzilla.gnome.org/show_bug.cgi?id=731756
First handle all miniobjects before we attempt to dereference the first
field pointer and look at the GType. With the recent glib change to
speed up G_IS_OBJECT, this causes crashes on miniobjects otherwise.
When a pad is added the need-parent flag is set to true, so when
they are removed the flag should be set back to false
This was preventing GstPads to be reused in elements (removed and
later re-added). A unit tests was added to verify that this is
working now.
The use case is tsdemux that has a program-number property and
allows the user to switch programs. In order to do that tsdemux
will remove the pads of the current program and add from the new
ones. The removed pads are kept in the demuxer for later if the
user selects the old program again.
Stores the last result of a gst_pad_push or a pull on the GstPad and provides
a getter and a macro to access this field.
Whenever the pad is inactive it is set to FLUSHING
API: gst_pad_get_last_flow_return
https://bugzilla.gnome.org/show_bug.cgi?id=709224
Currently there is no other way to unlock a buffer pool other then
stopping it. This may have the effect of freeing all the buffers,
which is too heavy for a seek. This patch add a method to enter and
leave flushing state. As a convenience, flush_start/flush_stop
virtual are added so pool implementation can also unblock their own
internal poll atomically with the rest of the pool. This is fully
backward compatible with doing stop/start to actually flush the pool
(as being done in GstBaseSrc).
https://bugzilla.gnome.org/show_bug.cgi?id=727611
When we call gst_buffer_pool_set_config() the pool may return FALSE and
slightly change the parameters. This helper is useful to do the minial required
validation before accepting the modified configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=727916
According to the documentation, when set_config() return false, it should be
possible to read the modified version of the config. This patch fixes the
implementation so it is now according to the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=727916
If a pool config is being configured again, check if the configuration have changed.
If not, skip that step. Finally, if the pool is active, try deactivating it.
https://bugzilla.gnome.org/show_bug.cgi?id=728268
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Currently we set TAG_MEMORY as soon a resize changes the size of one
of the memory. This has the side effect that buffer pool cannot know if
the memory have simply been resized, or if the memorys has been replaced.
This make it hard to actually implement _reset(). Instead, only set the
TAG_MEMORY if one or more memory has been replaced, and do a light
sanity check of the size.
https://bugzilla.gnome.org/show_bug.cgi?id=727109
We might not have reached PAUSED yet because of an async error,
but nonetheless we want to make sure that the pads are always
deactivated in READY state.
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
CID #1037132
This should allow for more meaningful errors. Dereferencing NULL
is more useful information than dereferencing a random address
happened to be on the stack.
We want to iterate over items idx to idx + length
We use the len variable as the corrected number of memory to iterate
and then properly go over all items.
Fixes the issue where specifying any idx different from 0 had no effect
Spotted by clang static analyzer
Events passing through #GstPads that have a running time
offset set via gst_pad_set_offset() will get their offset
adjusted according to the pad's offset.
If the event contains any information that related to the
running time, this information will need to be updated
before usage with this offset.
GST_DEBUG_BIN_TO_DOT_FILE() would cause a segfault whenever it encountered an
element's caps that had a field value being NULL. Such fields are successfully
handled e.g. by GST_*_OBJECT(), and with this patch so does
GST_DEBUG_BIN_TO_DOT_FILE(). Even if string fields with a NULL value are
not supposed to be valid in caps, such caps can be created.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727701
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
Spotted by Coverity.
Every instance of calling bin_do_message_forward() first took the
object lock, so that bin_do_message_forward() could drop it and
then reclaim. Instead, only take the object lock afterward where
needed.
Add loop_type and repeat_count fields to GstTocEntry plus setters and getters.
This allows to represent edit-lists in a toc as well as loops in instruemnts (wav, xi).
API: gst_toc_entry_set_loop
API: gst_toc_entry_get_loop
This ensures that the lock of the internal pad is held while referencing
it's peer (= the target pad), which ensures that the peer is not
going to be unlinked/destroyed in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=725809
This was plain text that had all list items one after the other (including a
repeated number). Now it will atleast look good when processed with gtk-doc
1.20.
Tag allocated buffers with TAG_MEMORY. When they are released later,
only add them back to the pool if the tag is still there and the memory
has not been changed, otherwise throw the buffer away.
Add unit test to check various scenarios.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724481
Use the technique that is now done in GTK+ so that the plugins do not have
to be installed in c:\gstreamer\lib\<debug>\gstreamer-$(GSTApiVersion),
but can be installed in
<parent_folder_of_gstreamer_main_dll>\lib\<debug>\gstreamer-$(GSTApiVersion),
or as per g_win32_get_package_installation_directory_of_module() allows.
https://bugzilla.gnome.org/show_bug.cgi?id=679115
... instead of returning a reference to a global instance. The caller might
want to change the global instance otherwise, which causes funny effects like
all global instances being changed and at the same time nothing in the caps
being changed.
As the caps might be immutable while we do this we have to do some magic
with atomic operations.
https://bugzilla.gnome.org/show_bug.cgi?id=723236
Keep an extra write ref on the control socket. This ensures that we
avoid a read/write on the socket when going from non-empty->empty->not-empty.
We remove the write ref only when we actually are empty and we need to
wait for flushing or a new buffer.
This makes the bufferpool benchmark about 30% faster than the pure
malloc implementation.
This way we make sure that a) the lock is always taken when checking
the cookie and calling the iterator's next functions and b) it is
not taken while calling any of the iterator filter functions.
https://bugzilla.gnome.org/show_bug.cgi?id=711138
events_foreach adds an extra ref when giving the event to the
user function. In case it was unrefed by the user, this extra ref
disappeared, but events_foreach still should unref again to
lose its own ref before removing the event from the array.
https://bugzilla.gnome.org/show_bug.cgi?id=722467
