For the query function there's a risk that the function may be called
after the harness has been teared down. Since the function accesses a
pointer to the harness via the pad's data, the harness must protect
itself against this.
Event and chain function is also handled for constistency, although
they don't have the same problem since the gstpad.c checks whether the
pad is flushing before calling these.
This was a misguided effort to try and guarantee the buffers of
the sink pads would not change during aggregate, when an upstream
branch is seeked independently, however this is simply incorrect
as downstream has not necessarily been flushed, or the aggregate
function might be waiting to receive buffers on other pads.
In !159 , we switched to sending flush_start ourselves from the
do_seek implementation. If no flushing seek successfully made its
way upstream, we need to send flush_stop ourselves as well.
Releasing a GRecMutex from a different thread is undefined
behaviour.
There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.
I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.
Instead of tracking "pending_flush_*" on the pads and the
aggregator, we now simply track the last seqnum for flush start
and flush stop events on the pads, and use it to determine whether
we should enter or exit our flushing state.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
Not that it matters, since we don't check the return value
anyway. Unclear why the aggregator pad flush function should
have a return value at all really, and perhaps it should be
called reset anyway. Spotted by dv on irc.
Another helper to navigate a pipeline. It makes it possible to easily
access the pads of an element:
(gdb) print $gst_element_pad(basesink, "sink")
$1 = 0x7fffe80770f0 [GstPad|sink]
This add the different timestamps for segment events:
(gdb) gst-print pad
SrcPad(src, push) {
events:
[...]
segment: time
rate: 1.1
start: 0:03:08.449753330
time: 0:03:08.449753330
position: 0:03:08.449753330
duration: 0:12:14.166687500
[...]
}
It shows a simple tree of all elements in pipeline.
As with gst-dot, the toplevel bin is found from any element of the
pipeline:
(gdb) gst-pipeline-tree bsink
playbin
inputselector1
inputselector0
uridecodebin0
queue2-0
decodebin0
avdec_aac0
aacparse0
vaapidecodebin0
vaapipostproc0
capsfilter1
vaapi-queue
vaapidecode0
capsfilter0
h264parse0
multiqueue0
matroskademux0
typefind
typefindelement0
source
playsink
abin
aconv
resample
conv
identity
aqueue
pulsesink0
vbin
vconv
scale
conv
identity
vqueue
vaapisink0
vdbin
deinterlace
vdconv
audiotee
streamsynchronizer0
This simplifies navigating in a GStreamer pipeline, e.g.
(gdb) print $gst_bin_get($gst_pipeline(pad), "matroskademux0")
$1 = 0x7fffe81b4050 [GstMatroskaDemux|matroskademux0]
For elements, this adds all child elements, the state and base/start time:
(gdb) gst-print pipeline
0x5555556ebd20 "pipeline0"
GstPipeline(pipeline0) {
children:
fakesink0
queue0
videotestsrc0
state: PLAYING
base_time: +2:54:36.892581150
start_time: 0:00:00.000000000
}
For pads, this adds the peer pads and the current task state and the
offset (if not zero):
(gdb) gst-print pad
SrcGhostPad(src, push) {
events:
[...]
peer: vaapisink0:sink
inner peer: scale:src
}
(gdb) gst-print pad
SrcPad(src, push) {
events:
[...]
peer: queue0:sink
task: STARTED
offset: 30000000 [+0:00:00.030000000]
}
* 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
The original version of the patch used glib-2.0 but that was later changed
to gstreamer-1.0 for autotools. The meson file was forgotten.
Fix the path to match the one used in libgstreamer-gdb.py.in.
It's possible that setcap is installed, but the libcap headers/libs aren't (e.g.
during cross compilation, when you have the program installed for the host,
but need the headers of the target). Also removes the need to manually check
for the libcap headers.
Internal gst_net_utils_set_socket_dscp renamed and turned into external
function. Similar functionality exists in e.g. multidupsink, which could
instead use this one.
The signal will be emitted when a buffer was consumed on
a pad, if the newly-added "emit-signals" property has been
set to TRUE.
Handlers connected to the signal will receive a valid reference on
the consumed buffer, allowing for example the retrieval of metas in
order to forward them once an output buffer is pushed out.
gstcheck.c:142: Warning: GstCheck: gst_check_add_log_filter: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)
gstcheck.h:178: Warning: GstCheck: gst_check_run_suite: argument suite: Unresolved type: 'Suite*'
gstharness.c: Use G_GSIZE_FORMAT instead of hard-coding %zu
error: unknown conversion type character 'z' in format [-Werror=format]
gst-inspect.c: GPid is void* on non-UNIX, and we only use it on UNIX
error: initialization makes pointer from integer without a cast [-Werror]
gstmeta.c: Use and then discard value
error: value computed is not used [-Werror=unused-value]
With this, gstreamer builds with -Werror on MinGW
This adds two custom gdb commands:
'gst-dot' creates dot files that a very close to what
GST_DEBUG_BIN_TO_DOT_FILE() produces. Object properties and buffer content
(e.g. codec-data in caps) are not available.
'gst-print' produces high-level information about GStreamer objects. This
is currently limited to pads for GstElements and events for the pads. The
output can look like this:
(gdb) gst-print pad.object.parent
GstMatroskaDemux (matroskademux0) {
SinkPad (sink, pull) {
}
SrcPad (video_0, push) {
events:
stream-start:
stream-id: 0463ccb080d00b8689bf569a435c4ff84f9ff753545318ae2328ea0763fd0bec/001:1274058367
caps: video/x-theora
width: 1920
height: 800
pixel-aspect-ratio: 1/1
framerate: 24/1
streamheader: < 0x5555557c7d30 [GstBuffer], 0x5555557c7e40 [GstBuffer], 0x7fffe00141d0 [GstBuffer] >
segment: time
rate: 1
tag: global
container-format: Matroska
}
SrcPad (audio_0, push) {
events:
stream-start:
stream-id: 0463ccb080d00b8689bf569a435c4ff84f9ff753545318ae2328ea0763fd0bec/002:1551204875
caps: audio/mpeg
mpegversion: 4
framed: true
stream-format: raw
codec_data: 0x7fffe0014500 [GstBuffer]
level: 2
base-profile: lc
profile: lc
channels: 2
rate: 44100
segment: time
rate: 1
tag: global
container-format: Matroska
tag: stream
audio-codec: MPEG-4 AAC audio
language-code: en
}
}
Fixes flaky appsrc unit test where depending on scheduling
the submitted list might not be writable if submitted via
an action signal from the application thread.
Fixes gst-plugins-base#522
baseparse internally uses a 64kb buffer for pulling data from upstream.
If a 64kb pull is failing with a short read, it would previously pull
again the requested size.
Doing so is not only inefficient but also seems to cause problems with
some elements (rawvideoparse) where the second pull would fail with EOS.
Short reads are only allowed in GStreamer at EOS.
Closes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/294
