gsttypefindhelper.c:485: Warning: GstBase: invalid "transfer" annotation for gsize: only valid for array, struct, union, boxed, object and interface types
This ensures the following special case is handled properly:
1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill level
Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data is
pushed in, and never post a 100% buffering message. The application will
have received a <100% buffering message from step #2, but will never see
100%.
Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.
https://bugzilla.gnome.org/show_bug.cgi?id=763757
If we don't store the value in prev_dts, we would over and over again
initialize the DTS from the last known upstream PTS. If upstream only provides
PTS every now and then, then this causes DTS to be rather static.
For example in adaptive streaming scenarios this means that all buffers in a
fragment will have exactly the same DTS while the PTS is properly updated. As
our queues are now preferring to do buffer fill level calculations on DTS,
this is causing huge problems there.
See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this part of
the code was introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=765096
Add missing 'else' and print caps and taglists without the
annoying duplicate string escaping, making both nicer to read.
Fixes string leak and coverity CID 1358492.
This previously caused uninitialized memory unless something else was
initializing all the fields explicitly to something.
To be on the safe side, we also allocate metas without init function to all
zeroes now as it was relatively common.
https://bugzilla.gnome.org/show_bug.cgi?id=764902
It is calling do_sync(), which requires the STREAM_LOCK and PREROLL_LOCK to be
taken. The STREAM_LOCK is already taken in all callers, the PREROLL_LOCK not.
https://bugzilla.gnome.org/show_bug.cgi?id=764939
We need to clear some global state and register a new test
basetransform subclass for each test because we do things
in class_init base on global state.
https://bugzilla.gnome.org/show_bug.cgi?id=623469
The test assumed that if a buffer has the same pointer address as
before it is in fact the same mini object and has been re-used by
the pool. This seems to be mostly true, but not always. The buffer
might be destroyed and when a new buffer is created the allocator
might return the same memory that we just freed.
Instead attach a qdata with destroy notify function to buffer
instances we want to track to make sure the buffer actually
gets finalized rather than resurrected and put back into the pool.
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
Checking the current element's state when we're adding pads to
the parent element is checking the wrong thing.
Silences a 'attempting to add an inactive pad to a running element'
warning when adding a ghost pad to a running parent bin of the parent
bin of the element.
https://bugzilla.gnome.org/show_bug.cgi?id=764176
This is a useful function to automatically add ghost pads when linking
two elements across bin boundaries without know their exact parentage.
e.g. when using gst_parse_bin_from_description (with or without it ghosting pads),
one can simply retreive the src/sink pads from the bin to link to another pad.
Similar functionality is provided by gst_element_link_pads{_full}() however only
by pad name rather than by actual pads.
API: gst_pad_link_maybe_ghosting_full
https://bugzilla.gnome.org/show_bug.cgi?id=764176
Updated the GST_REFCOUNTING logging so that it includes the pointer
address of the object that is being disposed or finalized.
With this change is is then possible to match up GST_REFCOUNTING log messages
for object allocation/disposal/finalization. This can help with diagnosing
"memory leaks" in applications that have not correctly disposed of all the
GStreamer objects it creates.
https://bugzilla.gnome.org/show_bug.cgi?id=749427
It returned TRUE when regression failed, while not setting any of the out
parameters. This caused uninitialized data from the stack to be used for
setting the clock calibration.
PUSH and PULL mode have opposite scenarios for IDLE and BLOCK
probes.
For PUSH it will BLOCK with some data type and IDLE won't have a type.
For PULL it will BLOCK before getting some data and will be IDLE when
some data is obtained.
The check in hook_marshall was specific for PUSH mode and would cause
PULL probes to fail to be called. Adding different checks for the mode
to fix this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=761211
We want to use the flag/enum nicks here, not only because they
are shorter but also because in case of element-specific enums
and flags we abuse the enum/flag name field for the description,
and we don't want that printed in the dot file.
https://bugzilla.gnome.org/show_bug.cgi?id=763814
Make compiler issue a warning for common beginner mistakes such as:
...
gst_buffer_make_writable (buf);
gst_buffer_map (buf, &map, GST_MAP_WRITE);
...
and similar. Only do this for some functions for now.
Don't keep the registry locked whilst iterating over the plugins
or features with a filter function. This would deadlock if the
callback tried to access the registry from the function. Instead,
make a copy of the feature/plugin list and then filter it without
holding the registry lock. This is still considerably faster than
the alternative which would be to use a GstIterator.
https://bugzilla.gnome.org/show_bug.cgi?id=756738
This takes readings in the form of ...
<local_1> <remote_1> <remote_2> <local_2>
... with one observation per line, and then replays it using the
netclientclock code.
The output is the statistics structure emitted by the netclientclock,
which can then be analysed and tuned once we get those readings for
potential edge-cases.
It should be possible to find some inputs with "bad" data and convert
this into a unit test for future tweaks to run against.
