rtpbasedepayload.c:126:5: error: unknown conversion type character 'z' in format [-Werror=format]
profile.c:688:10: error: unused variable 'gst_dir' [-Werror=unused-variable]
gst_video_decoder_negotiate_default_caps() is meant to pick a default output
format when we need one earlier because of an incoming GAP.
It tries to use the input caps as a base if available and fallback to a default
format (I420 1280x720@30) for the missing fields.
But the framerate and pixel-aspect were not explicitly passed to
gst_video_decoder_set_output_state() which is solely relying on the input format
as reference to get the framerate anx pixel-aspect-ratio.
So there is no need to manually handling those two fields as
gst_video_decoder_set_output_state() will already use the ones from
upstream if available, and they will be ignored anyway if there are not.
This also prevent confusing debugging output where we claim to use a
specific framerate while actually none was set.
gstrtspconnection.c: In function ‘writev_bytes’:
gstrtspconnection.c:1348:10: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return res;
^
Allow fallback to orc subproject if any.
Additionally 'dependencies' keyword is removed from find_library,
because it's invalid keyword for find_library.
When using multichannel audio data and being needed to reorder channels,
audio data is not copied correctly because destination address of
memcpy is wrong.
For example, the following command
$ gst-launch-1.0 pulsesrc ! audio/x-raw,channels=6,format=S16LE ! filesink location=test.raw
will reproduce this issue if there is 6-ch audio input device.
This commit fixes that.
The detailed process of this issue is as follows:
1. gst-launch-1.0 calls gst_pulsesrc_prepare (gst-plugins-good/ext/pulse/pulsesrc.c)
1466 gst_pulsesrc_prepare (GstAudioSrc * asrc, GstAudioRingBufferSpec * spec)
1467 {
(skip...)
1480 {
1481 GstAudioRingBufferSpec s = *spec;
1482 const pa_channel_map *m;
1483
1484 m = pa_stream_get_channel_map (pulsesrc->stream);
1485 gst_pulse_channel_map_to_gst (m, &s);
1486 gst_audio_ring_buffer_set_channel_positions (GST_AUDIO_BASE_SRC
1487 (pulsesrc)->ringbuffer, s.info.position);
1488 }
In my environment, after line 1485 is processed, position of spec and s are
spec->info.position[0] = 0
spec->info.position[1] = 1
spec->info.position[2] = 2
spec->info.position[3] = 6
spec->info.position[4] = 7
spec->info.position[5] = 8
s.info.position[0] = 0
s.info.position[1] = 6
s.info.position[2] = 2
s.info.position[3] = 1
s.info.position[4] = 7
s.info.position[5] = 8
The values of spec->info.positions equal
GST_AUDIO_BASE_SRC(pulsesrc)->ringbuffer->spec->info.positions.
2. gst_audio_ring_buffer_set_channel_positions calls
gst_audio_get_channel_reorder_map.
3. Arguments of gst_audio_get_channel_reorder_map are
from = s.info.position
to = GST_AUDIO_BASE_SRC(pulsesrc)->ringbuffer->spec->info.positions
At the end of this function, reorder_map is set to
reorder_map[0] = 0
reorder_map[1] = 3
reorder_map[2] = 2
reorder_map[3] = 1
reorder_map[4] = 4
reorder_map[5] = 5
4. Go back to gst_audio_ring_buffer_set_channel_positions and
2065 buf->need_reorder = TRUE;
is processed.
5. Finally, in gst_audio_ring_buffer_read,
1821 if (need_reorder) {
(skip...)
1829 memcpy (data + i * bpf + reorder_map[j] * bps, ptr + j * bps, bps);
is processed and makes this issue.
Otherwise we would return EOF if nothing was written in any case, even
if this was actually a case of TIMEOUT or EWOULDBLOCK for example.
Thanks to Edward Hervey for debugging and finding this issue.
Fixes 2 problems:
1) Number of unmapped memories does not always match number of mmaped ones in
dispatch_write().
2) When dispatch_write() is dispatched second time after an incomplete write,
already set offsets will not be taken into account, thus corrupt RTP data will
be sent.
This makes it unnecessary for callers to first merge together all
memories, and it allows API like GstRTSPConnection to write them out
without first copying all memories together or using writev()-style API
to write multiple memories out in one go.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/370
g_source_remove() works only for a GSource which was attached
to default GMainContext, but the GSource might be attached to
custom context depending on how gst_discoverer_start() was called.
Whatever the attached context was, g_source_destroy() can clean it up.
Make consistent with what autotools puts into enabled_gl_apis
variable. Autotools puts 'gl' in there instead of 'opengl'.
This would cause problems when building -bad glmixers plugin
in meson against a -base that was built with autotools.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/871
Otherwise surface_width/surface_height stored in GstGLWindowPrivate
isn't changed, sometimes an unnecessary reconfigure event is sent on
sinkpad, then result in upstream reconfiguring.
Example pipeline:
gst-launch-1.0 videotestsrc ! msdkvpp ! glimagesink
This reverts commit 69c3c31608.
All devices have the same name, they are duplicated with pulseaudio one
and the provided does not respond to HW being plugged/unplugged. I think
it's not ready for 1.16.
The start_time and end_time in this context have already
been adjusted for the input's rate by converting them to running
time above. What is needed afterwards is to compare these
with the output's start/stop running time, which also takes
into account the rate, so we are comparing equal things.
Multiplying these with the output's rate here is only breaking
this logic. In most cases the input and output rate is the same,
so this multiplication effectively reverses the rate adjustment
that happened while converting to running time, which is why
we see the video playing with the original rate in tests.
Fixes#541
Binding the vertex array to 0 will unbind everything else already.
In the previous order older versions of the Intel GL driver caused
errors to be printed for every single call when disabling the vertex
attrib arrays after binding the vertex array to 0.
We use all those libraries internally and include headers from them in
the public headers.
And add the tag library to Requires.private as we use it internally and
it would be needed when doing static linking.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/537
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
