Commit graph

1078 commits

Author SHA1 Message Date
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
Edward Hervey
794944f779 pad: Don't drop LATENCY queries with default implementation
If there is only one pad in the internal pads, when folding for
LATENCY queries it will just drop the response if it's not live.

This is maybe not the proper fix, but it will just accept the first
peer responses, and if there are any other pads, it will only take
them into account if the response is live.

This *should* properly handle the aggregation/folding behaviour of
multiple live peer responses, while at the same time handling the
simple one-pad-only-and-forward use-case

https://bugzilla.gnome.org/show_bug.cgi?id=766360
2016-05-13 11:36:12 +02:00
Sebastian Dröge
14f71d2e27 pad: Fix pad state when deactivating from one mode and then trying to activate another and failing
When activating a pad in PULL mode, it might already be in PUSH mode. We now
first try to deactivate it from PUSH mode and then try to activate it in PULL
mode. If the activation fails, we would set the pad to flushing and set it
back to its old mode. However the old mode is wrong, the pad is not in PUSH
mode anymore but in NONE mode.

This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream
actually fails to go into PULL mode after first PUSHING data to typefind.
2016-05-10 15:07:51 +03:00
Mark Combellack
b8f2929dac GST_REFCOUNTING: Add logging of pointer address for dispose, finalize, etc messages
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
2016-04-02 18:18:10 +01:00
Thiago Santos
368ee8a336 pad: rework probe's hook_marshall function
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
2016-03-28 11:14:41 -03:00
Thiago Santos
45b0e7aa16 pad: consider PROBE_TYPE_EVENT_FLUSH when using PROBE_TYPE_ALL_BOTH
When GST_PAD_PROBE_EVENT_FLUSH is used, the probes already have
a data type and it is not needed to automatically add the default
types.

https://bugzilla.gnome.org/show_bug.cgi?id=762330
2016-03-28 10:54:11 -03:00
Stian Selnes
7dd76b626e pad: Fix race between gst_element_remove_pad and state change
When going from READY to NULL all element pads are deactivated. If
simultaneously the pad is being removed from the element with
gst_element_remove_pad() and the pad is unparented, there is a race
where the deactivation will assert (g_critical) if the parent is lost at
the wrong time.

The proposed fix will check parent only once and retain it to avoid the
race.

https://bugzilla.gnome.org/show_bug.cgi?id=761912
2016-03-24 14:39:47 +02:00
Aurélien Zanelli
b7cffa4522 pad: add 'transfer full' and 'nullable' annotations to gst_pad_get_current_caps
and also change the description accordingly since function returns an
incremented caps object or NULL if there is no caps set.

https://bugzilla.gnome.org/show_bug.cgi?id=763912
2016-03-21 10:23:53 +02:00
Sebastian Dröge
42968bc949 Revert "pad: PULL probes are called without a buffer so don't require any of the data flags to be set"
This reverts commit b89fa4786b.

The changes break various tests.
2016-02-18 11:43:22 +02:00
Sebastian Dröge
b89fa4786b pad: PULL probes are called without a buffer so don't require any of the data flags to be set
https://bugzilla.gnome.org/show_bug.cgi?id=761211
2016-02-18 09:44:00 +02:00
Stefan Sauer
2f41e7bc6a tracer: harmonize the query hooks
In post hooks always pass the return value as the last param. Pass the query
also to post hooks since it is still alive.
2016-01-07 23:03:48 +01:00
Tim-Philipp Müller
7c992cfbe0 docs: fix some warnings and add some since markers 2016-01-03 17:50:35 +00:00
Edward Hervey
56d4650789 pad: Implement GstPadEventFullFunction
API: GstPadEventFullFunction

Returns a GstFlowReturn, allows asynchronous elements to properly
propagate flow returns

https://bugzilla.gnome.org/show_bug.cgi?id=757821
2015-12-02 16:04:03 +01:00
Thiago Santos
02d88fc3f3 pad: check template caps for proxy pads in accept-caps
Validate that the proxy pad indeed accepts the caps by also
comparing with the pad template caps, otherwise when the pad
had no internally linked pads it would always return true.

https://bugzilla.gnome.org/show_bug.cgi?id=754112
2015-11-06 10:23:34 -03:00
Jan Schmidt
ca22e60b91 pad: Mark sticky events as sent on not-linked
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
2015-11-01 23:16:44 +11:00
Sebastian Dröge
c47e49e1e3 pad: Unblock blocking pad probes when receiving FLUSH_START in send_event() too
Without this, flushing might not unblock the streaming thread and cause deadlocks.

https://bugzilla.gnome.org/show_bug.cgi?id=757257
2015-10-29 11:08:26 +02:00
Sebastian Dröge
1493f4a334 pad: Document the order in which pad probes are called
https://bugzilla.gnome.org/show_bug.cgi?id=757197
2015-10-28 13:04:25 +02:00