It might be the case that glgsinkbin would try to set a property to
its internal sink which doesn't exist in it, leading to a glib's
warning. For example, when playsink sets 'force-aspect-ratio' property
and glsinkbin has, as internal sink, appsink, which doesn't handle
that property.
The patch validates the incoming property to forward to internal sink
if it exists in the internal sink and both properties has the same
type.
We make an allocator for temporary lines and then use this for all
the steps in the conversion that can do in-place processing.
Keep track of the number of lines each step needs and use this to
allocate the right number of lines.
Previously we would not always allocate enough lines and we would
end up with conversion errors as lines would be reused prematurely.
Fixes#350
ISO 14496-3 defines that audioObjectType 5 is a special case that
indicates SBR is present and that an additional field has to be
parsed to find the true audioObjectType.
There are two ways of signaling SBR within an AAC stream - implicit
and explicit (see [1] section 4.2). When explicit signaling is used,
the presence of SBR data is signaled by means of the SBR
audioObjectType in the AudioSpecificConfig data.
Normally the sample rate is specified by an index into a
table of common sample rates. However index 0x0f is a special case
that indicates that the next 24 bits contain the real sample rate.
[1] https://www.telosalliance.com/support/A-closer-look-into-MPEG-4-High-Efficiency-AACFixes#39
(Initially discussed in
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/305)
The ticks waveform can be useful for audio synchronization diagnostics
and other cases where the time offset between waveforms is important.
However, in its current form, it is too limited, and has problems with
discontinuities, which result in severe artifacts when this waveform
is output by a DAC.
This patch fixes some discontinuities and considerably expand the ticks
waveform's flexibility. They also introduce the notion of a "marker tick";
every Nth tick can have a different amplitude (usually one that is larger
than the others). This is useful for combining frequent oscilloscope
triggering with large time offset detection. For example, without marker
ticks, the tick intervals must not be too small, otherwise the maximum time
offset that can be unambiguously detected is quite small (for example, if
the interval is 50ms, then no time offset larger than 25ms can be
unambiguously recognized). If the tick intervals are too far apart, then
no sudden changes can be clearly observed, since the oscilloscope is not
updated quickly enough. But with marker ticks, this is not an issue: If
there's for example a tick every 100 ms, then the oscilloscope can be
triggered every 100 ms. And, if every 20th tick is a marker tick, then
time offsets of up to 1 second can be discovered, even though the time
between ticks is 100 ms.
The patch also applies some minor cleanup to the audiotestsrc documentation.
Checking the address distance between given begin/end sequence
doesn't make sense. They are output params.
This is to fix weird failure of libs_rtp on Windows
Code in g_return_*() must not have side effects, as it
might be compiled out if -DG_DISABLE_CHECKS is used, in
which case we would read garbage off the stack.
Both versions are basically the same, but version 2.0 also allows
60000/1001 as framerate and allows to specify the field and line number
for each payload.
Put the major version into the caps so that elements can limit via caps
negotiation which versions they can support.
It breaks all the calculations. While it can make sense during
initialization, there's very little API that can be called with such
timecodes without ending up with wrong results.
The old API would only assert or return an invalid timecode, the new API
returns a boolean or NULL. We can't change the existing API
unfortunately but can at least deprecate it.
... instead of hardcoded ':', since G_SEARCHPATH_SEPARATOR_S
varies depending on OS (e.g., ':' for *nix and ';' for Windows).
Note that, when the seperator is not specified explicitly, Meson
will use ';' for Windows and ':' for *nix respectively.
audioconvert's passthrough status can no longer be determined
strictly from input / output caps equality, as a mix-matrix can
now be specified.
We now call gst_base_transform_set_passthrough dynamically, based
on the return from the new gst_audio_converter_is_passthrough()
API, which takes the mix matrix into account.
The presence of `key-mgmt` attribute will set the mikey appropriately.
We therefore don't need to check the return value (which will
be overwritten afterwards).
