The function rtcp_packet_min_length() returns a length for each known type
and -1 for unknown types. This change fixes the test accordingly and silences
the following warning.
gstrtcpbuffer.c:567:12: error: comparison of constant -1 with expression of type 'GstRTCPType' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
if (type == -1)
Fix the following warnings by adding casts.
gstdiscoverer.c:1801:17: error: format specifies type 'unsigned long' but the argument has type 'off_t' (aka 'long long') [-Werror,-Wformat]
location, file_status.st_size, file_status.st_mtime);
^~~~~~~~~~~~~~~~~~~
gstdiscoverer.c:1801:38: error: format specifies type 'long long' but the argument has type '__darwin_time_t' (aka 'long') [-Werror,-Wformat]
location, file_status.st_size, file_status.st_mtime);
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/570
Before a gap event is pushed downstream a segment event must be pushed
since the gap event can cause packet concealment downstream and hence
data flow. Since concealment before receiving any data packets usually
doesn't make any sense, the gap event is not sent downstream.
Alternatively one could generate a default caps and segment event, but
no need to complicate things until it's proven necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=773104https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/301
The former code allowed an attacker to create a heap overflow by
sending a longer than allowed session id in a response and including a
semicolon to change the maximum length. With this change, the parser
will never go beyond 512 bytes.
Using a single condition variable for synchronization across all GL
messages is very slow on Windows and uses up to 20% CPU usage in some
workloads due to lock contention and false broadcasts.
Using per-message event handles reduces the CPU usage to negligible
amounts despite having to allocate a new event handle for each
message.
Implement the prepare and check functions according to the
documentation by returning TRUE when events should be dispatched
via the dispatch function.
As wl_display_read_events never blocks we can call it unconditionally
without looking at the poll status.
This simplifies the implementation and gets rid of a race where the
mainloop could get blocked due to nobody actually reading the events
from the wayland connection.
The ->skip_buffer implementation in videoaggregator replicates
the behaviour of the aggregate method to determine whether a
buffer can be skipped
(https://bugzilla.gnome.org/show_bug.cgi?id=781928).
This fixes a typo that made it so the start time of the buffer
was calculated against the output segment, not the segment of
the relevant sinkpad, which caused buffers to be skipped when
for example a sinkpad had received a segment which base had
been modified by a pad offset somewhere along the way.
This simply makes the calculation of the buffer start time
identical to the calculation in aggregate()
Doing so involves retrieving the current viewport from OpenGL which as
with any glGet operation, is expensive.
This means that the various sinks need to reset the viewport on draw.
In the process, fix resizing on cocoa.
If we only ever make it to READY, transform_caps can create an
internal convert object that will never be freed by basetransform's
stop vmethod (PAUSED->READY).
This allows us to output audio samples without discarding
any input frames, which is useful for some formats/codecs
(e.g. the MonkeysAudio decoder implementation in ffmpeg
which will might return e.g. 16 output buffers for an
input buffer for certain files).
In the past decoder implementations just concatenated
the returned audio buffers until a full frame had been
decoded, but that's no longer possible to do efficiently
when the decoder returns audio samples in non-interleaved
layout.
Allowing subframes to be output before the entire input
frame is decoded can also be useful to decrease startup
latency/delay.
https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/49
The use of mediump as a specifier in GLSL shaders will have limited
resolution and when used as texture coordinates may become inaccurate
over texture sizes of 1024.
The function fill_bytes could sometimes return a value greater than zero
and in the same time set the GError.
Function read_bytes calls fill_bytes in a while loop. In the special
case above it would call fill_bytes with error already set.
Thus resulting in "GError set over the top of a previous GError".
Solved this by clearing GError when return value is greater than zero.
Actions are taken depending on error type by caller of read_bytes. Eg.
with EWOULDBLOCK gst_rtsp_source_dispatch_read will try to read the
missing bytes again (GST_RTSP_EINTR )
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/445
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;
^
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.
