API: GST_LEVEL_MAX
By compiling gstreamer (or plugins) with GST_LEVEL_MAX defined, only
the debugging statements at or below that level will be compiled in.
This allows compiling in some debugging (like errors and warnings) which
helps in debugging, but without the full cpu/memory overhead of all debugging
enabled.
Pools are allowed to change the size in order to adapt padding. So
don't check the size. Normally pool will change the size without
failing set_config(), but it they endup changing the size before
the validate method may fail on a false positive.
https://bugzilla.gnome.org/show_bug.cgi?id=741420
Add a function to check if the preset iface implementation is editable and
document this from the implementers perspective.
API: gst_preset_is_editable()
gstdebugutils.c: In function 'gst_debug_bin_to_dot_data':
gstdebugutils.c:683:530: error: 'return' with no value, in function returning non-void [-Werror]
g_return_if_fail (GST_IS_BIN (bin));
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
The documentation states that gst_element_send_event is to "send an event
to an element".
Therefore we *send* upstream events to a source pad and downstream events
to a sink pad
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
Added back after previous revert, as it's been double checked.
https://bugzilla.gnome.org/show_bug.cgi?id=740003
Previously, dropping a query from a pad probe would deem the
query succeeded, and the caller might then assume the query's
results are valid, and thus dereference an invalid object
such as a GstCaps.
We now assume dropped queries did not succeed. Dropped events
and buffers are still deemed a success.
If a task thread is calling pause on it self and the
controlling/"main" thread stops the task, it could end in a race
where gst_task_func loops and then checks for paused after the
controlling thread just changed the task state to stopped.
Hence the task would actually call func again even though it was
both paused and stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=740001
It's architecture dependent and should not be placed into the include
directory as the assumption is that all those headers are architecture
independent.
https://bugzilla.gnome.org/show_bug.cgi?id=739767
The GST_INFO ("initialized GStreamer succesfully") is currently at the end of
gst_init_check which isn't guaranteed to be run since GStreamer can be
initialized by using init_pre and init_post directly from GOptionContext like
gst-launch does. Ensure this message is displayed by moving it to init_post.
Use some macros to make our value functions setup a bit
tidier, and micro-optimise a few reallocs by setting an
initial size for the global type arrays.
Remove a useless assert (we just instantiated this type). Drop the free'ing of
the extension array. As we just created the instance this is always NULL.
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
