Commit graph

1094 commits

Author SHA1 Message Date
Miguel Paris
fad603011d pad: clear probes holding mutex
Protect clearing probes against concurrent modification which might happen
due to dispose does NOT guarantee that the object is not used anymore, as
it could be referenced again and so being continued used.
So, as in the rest of places where probes hook list is used, on dispose
it should be accessed holding the mutex "GST_OBJECT_LOCK (pad);" as
GHookList is not thread-safe.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/798>
2021-04-19 14:58:43 +02:00
Jan Schmidt
170f694198 pad: Fix for multiple blocking probes interaction.
Change the way the marshalled flag in the internal ProbeMarshall state
is handled when iterating over pad probes so that it only counts
probes that still exist and would be called when retrying.

This improves the way that removing a blocking probe works when
there are multiple blocking probes for different conditions (data vs
events for example).

As a side-effect, probes aren't put into the the called_probes array
unless they actually match the current probe type and would be called,
potentially reducing the number of hooks that get stored in the
called_probes array, and the cost of the looping check on retries.

Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/658

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/749>
2021-02-10 13:43:28 +11:00
Edward Hervey
5e553b8cce gstpad: Simplify task name creation
This was going through a few locks and doing temporarily allocations for every
single task creation.. just to get a name.

We don't need to take locks since:
* The parent exists (we have a reference to it)
* The pad exists (the task belongs to it)
* Changing names of pad/elements when activating is a big no-no

Instead use the existing direct GST_DEBUG_PAD_NAME macro

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/455>
2020-05-04 12:26:10 +00:00
Edward Hervey
7a207da733 gstevent: Add function for checking event name by GQuark
Avoids doing string<=>quark conversions in the sticky event handling path.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/455>
2020-05-04 12:26:10 +00:00
Sebastian Dröge
ed1022fa81 Use gst_object_unref() / gst_object_clear() instead of the GObject ones
To allow the refcounting tracer to work better. In childproxy/iterator
these might be plain GObjects but gst_object_unref() also works on them.
In other places where it is never GstObject, g_object_unref() is kept.
2020-04-20 16:28:52 +00:00
Sebastian Dröge
606a9acd74 pad: Add a guard against getrange functions not filling a caller-provided buffer
It's a programming error to not do so and would cause all kinds of
problems in the caller that assumed its own buffer to have been filled.
2020-04-02 13:47:37 +03:00
Nayana Topolsky
e8c782d119 pad: clear sticky event tag upon stream-start
When playing gapless there were situations when some sticky events
like tags were stuck at some pad and then revived much later.
Therefore it is better to clear them upon stream-start.

Fixes #360
2019-11-04 12:01:47 +00:00
Niels De Graef
4812c4087f Don't pass default GLib marshallers for signals
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.

Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
2019-09-09 12:16:24 +00:00
Vivia Nikolaidou
7774aae713 pad: Added gst_pad_get_single_internal_link
gst_pad_iterate_internal_links is usually used to find a single internal
link that a pad has, e.g. to find the corresponding pad of a multiqueue.
Added a helper function that will return either a single internal link,
if there's no other, or NULL.
2019-09-05 11:49:18 +03:00
Havard Graff
ce7e6a9406 pad: increase debug-level to warning for fatal outcomes 2019-06-13 16:30:14 +00:00
Edward Hervey
7aee718394 gstpad: Probes that return HANDLED can reset the data info field
Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
where some probes would reset the probe info data field to NULL. This would
be considered an invalid use-case.

But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
the probe has "handled" it.
2019-05-16 15:13:48 +02:00
Thibault Saunier
949fba4b1f doc: Fix hotdoc warnings
* Making sure that `static inline` function are in the GIR (by first
  defining them, and make sure to mark as skiped)
* Do not try to link to unexisting symbols
* Also generate GIR information about gst_tracers
2019-05-13 16:34:09 -04:00
Lawrence Troup
2276336621 pad: Document that pad unlink function is called with pad lock held
Fixes #353
2019-02-13 11:56:15 +00:00
Sebastian Dröge
f6816d5412 pad: Constructors are all not nullable
They can't possibly return NULL except in case of assertions.
2019-01-29 14:49:28 +00:00
Nicolas Dufresne
c816ec4f0e pad: Remove unneeded 64bit upcast in debug trace
The hook->hook_id is a gulong for which there are no portability issues
when tracing in printf format with %lu. So use %lu and remove the upcast
to 64 bit. This makes the code more consistent with everything else
tracing that hook_id and other gulong id.
2019-01-26 01:42:22 +00:00
Sebastian Dröge
a143d9cb0c pad: Fix printf format when printing hook id
It's a gulong so we have to cast it to a guint64 when using it with
G_GUINT64_FORMAT.

Spotted by Vincent Penvern.
2019-01-15 16:07:04 +00:00
Sebastian Dröge
4af3b3f159 pad: Print some debug information about pad probe hooks we remove 2018-12-14 18:37:53 +02:00
Matthew Waters
4fc4ad87d5 query: add a new bitrate query
Allows determining from downstream what the expected bitrate of a stream
may be which is useful in queue2 for setting time based limits when
upstream does not provide timing information.

Implement bitrate query handling in queue2

https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/60
2018-11-07 15:04:14 +00:00
Havard Graff
4b3872f757 gstpad: use hook_id instead of hook in called_probes list
A pointer to a hook in this list can easily not be unique, given both
the slice-allocator reusing memory, and the OS re-using freed blocks
in malloc.

By doing many repeated add and remove of probes, this becomes very easily
reproduced.

Instead use hook_id, which *is* unique for a added GHook.
2018-11-06 10:04:00 +01:00
Sebastian Dröge
e6e22af828 Revert "pad: Don't drop LATENCY queries with default implementation"
This reverts commit 794944f779.

Accumulating non-live latency values generally makes no sense and often
gives invalid results with min>max
2018-08-31 12:16:43 +03:00
Sebastian Dröge
5c4317c399 Revert "pad: Accumulate live/non-live latency values separately"
This reverts commit f5783e1cac.
2018-08-31 12:16:43 +03:00
Sebastian Dröge
f5783e1cac pad: Accumulate live/non-live latency values separately
And only ever use the non-live values if all pads are non-live,
otherwise only use the results of all live pads.

It's unclear what one would use the values for in the non-live case, but
by this we at least pass them through correctly then.

This is a follow-up for 794944f779, which
causes wrong latency calculations if the first pad is non-live but a
later pad is actually live. In that case the live values would be
accumulated together with the values of the non-live first pad,
generally causing wrong min/max latencies to be calculated.
2018-08-31 11:44:34 +03:00
Sebastian Dröge
babd0e5f5d pad: Update pad offsets on the current event if the offset changed in pad probes
https://bugzilla.gnome.org/show_bug.cgi?id=796898
2018-08-01 14:23:04 +03:00
Sebastian Dröge
c3d3cf074e pad: Ensure that the pad is blocked for IDLE probes if they are called from the streaming thread too
IDLE probes that are directly called when being added will increase /
decrease the "number of IDLE probes running" counter around the call,
but when running from the streaming thread this won't happen.

This has the effect that when running from a streaming thread it is
possible to push serialized events or data out of the pad without
problems, but otherwise it would deadlock because serialized data would
wait for the IDLE probe to finish first (it is blocking after all!).

With this change it will now always consistently deadlock instead of
just every once in a while, which should make it obvious why this
happens and prevent racy deadlocks in application code.

https://bugzilla.gnome.org/show_bug.cgi?id=796895
2018-08-01 14:23:04 +03:00
Sebastian Dröge
2aa9ad9c62 Revert "pad: Handle changing sticky events in pad probes"
This reverts commit 11e0f451eb.

When pushing a sticky event out of a pad with a pad probe or pad offset,
those should not be applied to the event that is actually stored in the
event but only in the event sent downstream. The pad probe and pad
offsets are conceptually *after* the pad, added by external code and
should not affect any internal state of pads/elements.

Also storing the modified event has the side-effect that a re-sent event
would arrive with any previous modifications done by the same pad probe
again inside that pad probe, and it would have to check if its
modifications are already applied or not.

For sink pads and generally for events arriving in a pad, some further
changes are still needed and those are tracked in
  https://bugzilla.gnome.org/show_bug.cgi?id=765049

In addition, the commit also had a refcounting problem with events,
causing already destroyed events to be stored inside pads.
2018-07-23 23:17:54 +03:00
Tim-Philipp Müller
2db8e3705f Update for g_type_class_add_private() deprecation in recent GLib
https://gitlab.gnome.org/GNOME/glib/merge_requests/7
2018-06-24 12:49:14 +02:00
Sebastian Dröge
13d5957fd7 pad: Fix race condition causing the same probe to be called multiple times
Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.

https://bugzilla.gnome.org/show_bug.cgi?id=795987
2018-05-11 18:54:55 +03:00
luz.paz
4a402c1c7d Fix typos in comments and docs
Found via `codespell`

https://bugzilla.gnome.org/show_bug.cgi?id=795610
2018-05-01 11:18:03 +01:00
Thibault Saunier
11e0f451eb pad: Handle changing sticky events in pad probes
In the case where the user sets a new padprobeinfo->data in a probe
where the data is a sticky event, the new sticky event should be automatically
sticked on the probed pad.

https://bugzilla.gnome.org/show_bug.cgi?id=795330
2018-04-17 13:36:26 -03:00
Mathieu Duponchelle
60fae518b0 pad: fix mixed declarations 2018-03-01 01:09:48 +01:00
Mathieu Duponchelle
7847e69ef8 pad, ghostpad: use the template gtype if specified
Also make sure the GType passed to the with_gtype versions
of the template constructors is_a GstPad

https://bugzilla.gnome.org/show_bug.cgi?id=793933
2018-03-01 00:39:08 +01:00
Arun Raghavan
b5028383ab gst: Fix up a bunch of GIR annotations
This is mostly on nullable return values, and some other minor ones that
I ran across.

https://bugzilla.gnome.org/show_bug.cgi?id=789319
2018-01-27 10:41:24 +00:00
Edward Hervey
31383e4413 gstpad: Avoid stream-dead-lock on deactivation
The following case can happen when two thread try to activate and
deactivate a pad at the same time:
T1: starts to deactivate, calls pre_activate(), sets in_activation
    to TRUE and carries on
T2: starts to activate, calls pre_activate(), in_activation is TRUE
    so it waits on the GCond
T1: calls post_activate(), tries to acquire the streaming lock ..
    but can't because T2 is currently holding it

With this patch, the deadlock will no longer happen but does not
solve the problem that:
T2: will resume activation of the pad, set the pad mode to the target
   one (PUSH or PULL) and eventually the streaming lock gets released.
T1: is able to finish calling post_activate() ... but ... the pad
   wasn't deactivated (T2 was the last one to "activate" the pad.

https://bugzilla.gnome.org/show_bug.cgi?id=792341
2018-01-16 10:29:18 +01:00
Edward Hervey
6cd783b9fc gstpad: Release pending g_cond_wait() when stopping/pausing task
Otherwise we would deadlock waiting forever for the streaming lock
to be released

https://bugzilla.gnome.org/show_bug.cgi?id=792341
2018-01-15 18:19:48 +01:00
Edward Hervey
0afc114629 gstpad: Handle GST_PAD_PROBE_HANDLED on sticky event push
When actually pushing an event, if we get GST_FLOW_CUSTOM_SUCCESS_1
(which is the conversion of GST_PAD_PROBE_HANDLED return value),
don't consider the stick event push as ignored, but as handled
2017-12-06 17:23:05 +01:00
Stian Selnes
512cec3dea pad: gst_pad_activate_mode() always succeed if same mode
Checking that the pad is in the correct mode before the parent is
checked makes the call always succeed if the mode is ok.

This fixes a race with ghostpad where gst_pad_activate_mode() could
trigger a g_critical() if the ghostpad is unparented while the
proxypad is deactivating, for instance if the ghostpad is released.
More specifically, gst_ghost_pad_internal_activate_push_default()'s
call to gst_pad_activate_mode() would fail if ghostpad doesn't have a
parent. With this patch it will return true of mode is already
correct.
2017-11-24 13:40:31 +01:00
Edward Hervey
d915dd4b20 gstpad: Make pad (de)activation atomic
The following could happen previously:
* T1: calls gst_pad_set_active()
* T2: currently (de)activating it
* T1: gst_pad_set_active() returns, caller assumes that the pad has
  completed the requested (de)activation ... whereas it is not
  the case since the actual (de)activation in T2 might still be
  going on.

To ensure atomicity of pad (de)activation, we use a internal
variable (and cond) to ensure only one thread at a time goes through
the actual (de)activation block

https://bugzilla.gnome.org/show_bug.cgi?id=790431
2017-11-16 10:55:36 +01:00
Edward Hervey
80262013ca gstpad: Make calls to GstPadActivateFunction MT-safe
checking whether we already were in the target GstPadMode was being
done too early and there was the risk that we *would* end up
(de)activating a pad more than once.

Instead, re-do the check for pad mode when entering the final pad
(de)activation block.

https://bugzilla.gnome.org/show_bug.cgi?id=790431
2017-11-16 08:29:22 +01:00
Edward Hervey
aed32ee2ab pad: Don't call remaining probes after they return DROPPED|HANDLED
If multiple probes are set on a pad and one probe returns either
GST_PAD_PROBE_HANDLED or GST_PAD_PROBE_DROPPED we need to stop
calling the remaining probes.

https://bugzilla.gnome.org/show_bug.cgi?id=787243
2017-09-04 14:37:42 +02:00
Sebastian Dröge
087eca8827 pad: Recheck sticky events after non-blocking buffer probes and blocking event probes
Without the former, event changes (e.g. setting a pad offset) does not
take effect for the current buffer but only for the next one. Without
the latter, non-blocking event probes would not see any updated events
yet.
2017-08-02 21:02:32 +03:00
Tim-Philipp Müller
08ee7a86ed pad: add since marker to docs for new API 2017-02-24 21:35:27 +00:00
Thibault Saunier
6326c764ee pad: Add API to get the current state of a task
Avoiding the user to need to deal with the locking himself etc.

API:
  gst_pad_task_get_state

https://bugzilla.gnome.org/show_bug.cgi?id=778830
2017-02-24 16:16:23 -03:00
Thibault Saunier
a87b4551a6 Port gtk-doc comments to their equivalent markdown syntax
Modernizing our documentation and preparing a possible move to hotdoc.
This commits also adds missing @title metadatas to all SECTIONs
2017-01-27 16:36:38 -03:00
Reynaldo H. Verdejo Pinochet
eb9c8bdf66 gstpad: only warn on performance penalty if not using the template caps
After b76ecfd992 introduced
GST_PAD_FLAG_ACCEPT_TEMPLATE, the performance penalty this
message is refering to (the cascading ACCEPT_CAPS query)
only applies to the cases where !GST_PAD_IS_ACCEPT_TEMPLATE
2016-12-14 00:01:34 -08:00
Stefan Sauer
0dbf978eb4 tracer: move the PAD_LINK tracer hook to _pad_link_full()
This is ultimately executing the pad_link. In the previous position we missed
some links, notably ghostpads.
2016-12-08 20:20:17 +01:00
Thiago Santos
83cac0f7b6 pad: add no-reconfigure link check
Enable it to prevent sending reconfigure when linking elements.

Useful for autoplugging when we know caps or bufferpools shouldn't change
to save doing caps renegotiation to end up with the same final scenario.

The no-reconfigure is not a proper check, it is a flag. It is implemented
as a GstPadLinkCheck to avoid creating another gst_pad_link variant.

https://bugzilla.gnome.org/show_bug.cgi?id=757653
2016-11-01 20:28:14 +02:00
Jan Schmidt
9fd2101b36 events: Implement the stream-group-done event
A new event which precedes EOS in situations where we
need downstream to unblock any pads waiting on a stream
before we can send EOS. E.g, decodebin draining a chain
so it can switch pads.

https://bugzilla.gnome.org/show_bug.cgi?id=768995
2016-07-25 20:22:20 +10:00
Guillaume Desmottes
2a0bba69e1 pad: add g-i transfer annotatation to _store_sticky_event()
For clarity.

https://bugzilla.gnome.org/show_bug.cgi?id=768810
2016-07-15 12:50:21 +01:00
Miguel París Díaz
9f982e2d75 pad: check query caps answered and caps not NULL
https://bugzilla.gnome.org/show_bug.cgi?id=768450
2016-07-07 10:08:15 +03:00
Sebastian Dröge
37713c3388 pad: Log pad offsets as signed times 2016-06-11 22:18:22 +03:00