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
Without this bindings get confused about the meaning of references, and
we really own these references if they are not already owned by
something else.
We won't be able to do ASSERT_CRITICAL, but the main body of the tests
are still valid, and given we ship GStreamer with this configuration, it
is important to be able to run some tests against it.
This adds gdb pretty printer for some GStreamer types.
For GstObject pointers the type and name is added, e.g.
"0x5555557e4110 [GstDecodeBin|decodebin0]".
For GstMiniObject pointers the object type is added, e.g.
"0x7fffe001fc50 [GstBuffer]".
For GstClockTime and GstClockTimeDiff the time is also printed in human
readable form, e.g. "150116219955 [+0:02:30.116219955]".
Fixes#320
By moving the functionality down to the testclock, the implementation
no longer needs to poll the waits, but rather wait properly for
them to be added.
The performance-hit here would be that by polling the test-clock
regularly, you would create contention on the testclock-lock, making code
using the testclock (gst_clock_id_wait) fighting for the lock.
Previously, with opportunistic sync we'd track a master
clock as soon as we see a SYNC message, and hence sync up
faster, but then we'd announce we're synched before seeing
the ANNOUNCE, leaving the clock details like grandmaster-clock
empty.
A better way is to start tracking the clock opportunistically,
but not announce we're synched until we've also seen the ANNOUNCE.
The follow-up and delay-resp messages carry precise
timestamps for the arrival at the clock master, but
the local return time is unimportant, so we should be very
lenient in accepting them late. Some PTP masters don't
prioritise sending those packets, and we reject all the
responses and never sync - or take forever to do so.
Increase the tolerance to 20x the mean path delay.
Also fix a typo in one debug output that would print
the absolute time of the delay-resp message, not the offset
from the delay-req that it's actually being compared against.
gst_queue_array_clear will clear the GstQueueArray,
gst_queue_array_set_clear_func will set a clear function for each
element to be called on _clear and on _free.
https://bugzilla.gnome.org/show_bug.cgi?id=797218
This is exposed as a solution to the use case of plugging in
sources with a higher latency after the aggregator has started
playing with an initial set of sources, allowing to avoid resyncing.
https://bugzilla.gnome.org/show_bug.cgi?id=797213
Otherwise we try to build a shared lib when we build the rest
of GStreamer statically, which won't work because we pass
-DGST_STATIC_COMPILATION when building statically, which means
we won't dllimport public symbols from our libs which means
that on Windows the unit tests will fail to link to libgstcheck.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
Fixes a configure error with gst-build:
subprojects/gst-plugins-base/meson.build:235:2: ERROR: Fetched variable 'gst_check_dep' in the subproject 'gstreamer' is not a dependency object.
The avg_bitrate is an unsigned int, so the gst_util_uin64_scale() function can't
be used for it, as it expects signed integers for the fraction parts arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=797054
Make our own deprecation marker for libgstcheck,
since the function declaration must contain the
right API export decorator (GST_CHECK_API) and
not the one for GStreamer core.
Don't return a value from a function that doesn't
return a value using the returned value from a
function that also doesn't return a value.
gstbitwriter.h(265): warning C4098: 'gst_bit_writer_align_bytes_unchecked': 'void' function returning a value
Instead, use -fvisibility=hidden and explicit exports via GST_EXPORT.
This should result in consistent behaviour for the autotools and
Meson builds where this is done already, and will allow us to drop
the win32 .def files.
And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
And make use of that in the typefind element to also be able to make use
of the extension in push mode. It previously only did that in pull mode
and this potentially speeds up typefinding and might also prevent false
positives.
https://bugzilla.gnome.org/show_bug.cgi?id=796865
gst_base_transform_transform_caps can return NULL in various conditions
thus we should not treat its result as valid caps.
In all other places NULL is properly handled.
The processing deadline is the acceptable amount of time to process the media
in a live pipeline before it reaches the sink. This is on top of the algorithmic
latency that is normally reported by the latency query. This should make
pipelines such as "v4lsrc ! xvimagesink" not claim that all frames are late
in the QoS events. Ideally, this should replace max_lateness for most applications.
https://bugzilla.gnome.org/show_bug.cgi?id=640610
We need all relevant events of a segment to have consistent seqnum:
* GST_EVENT_SEGMENT
* GST_EVENT_EOS
If we are push-based and create a new segment, use the same seqnum
as the upstream event.
If we are pull-based, use the seqnum of that newly created segment
event everywhere
