When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
The install kwarg on configure_file() was only added in
Meson 0.50 but we're targetting older versions as well,
which caused a warning. The install kwarg is not needed
here as we specify install_dir, so we can just drop it.
Fixes#379
The documentation says that this allows the subclass to signal that it
needs more data before it can decide on caps, so let's actually
implement it that way.
When passing "sink_%d" twice to aggregator before it would create two
pads called "sink_0", because it failed to parse "%d" as integer and
used 0 instead then.
Instead validate that parsing was actually successful and also don't
even try to parse if the requested pad name contains a '%'.
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.
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.
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.
