| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This causes 'redefinition of typedef ...' errors on GCC 4.5.3
|
| |
|
|
|
|
|
|
|
| |
If we use the main loop it might happen that the caller (e.g. our unit
test) already shut down the loop once the result was received and in
that case the pipeline would never ever be shut down (and our unit test
would hang).
|
|
|
|
| |
PAUSED failed
|
|
|
|
| |
We only care for the pre-roll sample.
|
|
|
|
| |
failed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While this creates a circular reference between the pipeline and the
context, this ensures that the context stays alive for as long as any
callbacks could be called on it. The circular reference is broken once
the conversion is finished (or error, or timeout), which will then cause
everything to be freed.
Previously it was possible that a callback could be called on the
context right after it was freed already.
Also use only a single context structure, the second structure does not
simplify anything and duplicates storage.
|
| |
|
|
|
|
|
|
|
| |
The current sequence number will be the one from the first RTP buffer
when a buffer list is pushed, but should be the last one.
Fixes #495
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather then letting gst_gl_memory_setup_buffer guess the GL format used
for an eglimage after importing a dmabuf be explicit about it. This
fixes issues where dmabuf import may have used another format then
gst_gl_format_from_video_info would guess on the basis of the available
GL extensions.
In particular on etnaviv the gst_gl_format_from_video_info would
assuming a luminance + alpha GL format is used for YUY2, but the dmabuf
import will always use RG88. Which causes images to end up somewhat pink when
displayed on the screen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When importing an egl image from dmabuf gst_gl_format_from_video_info
was used to work what the result GL format will be. Unfortunately that
will only work if the conventional format and the choosen DRM fourcc for
the format match up.
On etnaviv platforms there is no support for GL_EXT_texture_rg, so the
GL format chosen for YUY2 ends up being GST_GL_LUMINANCE_ALPHA. However
DRM does not do luminance + alpha as it's a legacy GL thing, so the
dmabuf import ends up using DRM_FORMAT_GR88.
To fix this, tie the DRM_FORMAT and the GL format together so they
always match up.
|
|
|
|
|
|
| |
compat_includes only exists in master.
Fixes #507
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the internal viewconvert to not scale buffers for output with the
following pipeline:
gltestsrc ! glimagesink
It also fixes overlay composition with a resized output with an OpenGL
upstream:
gltestsrc ! timeoverlay ! glimagesink
|
|
|
|
|
|
|
|
|
| |
Attempting to use the MAX(1, display_rect) would result in the overlay
composition attempting to draw into 1x1 buffer and calculate some
grossly incorrect sizes.
previously failing case:
gltestsrc ! textoverlay text=GStreamer ! glimagesinkelement
|
| |
|
|
|
|
|
| |
We can get away with ensuring that the memory:GLMemory caps feature is
present in the output caps
|
|
|
|
|
| |
For distros that provide headers in seperate dev/devel packages this
won't build egl support without the necessary EGL headers.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have a transformation matrix, we have no idea where in the output
the video is going to endup. It might also be different and not cover
the entire output.
We need to clear the output to remove any previous data in the backing
texture.
Found from
https://stackoverflow.com/questions/51707229/python-gstreamer-for-dynamic-control-of-element-properties
|
|
|
|
|
|
|
|
| |
gst_gl_memory_setup_buffer() was not properly using the number
of pointers to wrapped. This also fixes the validation, as we
only support 1 wrapper per view, or num_planes * views wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=796860
|
| |
|
|
|
|
| |
Otherwise it's very easy to miss them when gst_video_frame_map() fails
|
|
|
|
|
|
|
|
|
| |
rtsp_connection_send takes care of adding those already,
and some reverse proxies such as nginx will reject the request
altogether if the Authorization header is present twice,
even with the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=797272
|
|
|
|
|
|
| |
It was checking for GST_IS_CAPS only and that would fail if the new
restriction caps was NULL and its documentation says it accepts NULL as
valid input.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This may be a cause of out-of-place frames when transforming multiview
buffers.
|
|
|
|
|
|
|
|
|
|
|
| |
If we have an upstream GST_EVENT_STREAM_START, use that one instead
of creating a new one which could be completely different from the
upstream one and drop information (like the stream flags and stream
object).
Only create a new event if we don't already have one from upstream
https://bugzilla.gnome.org/show_bug.cgi?id=797215
|
| |
|
|
|
|
|
| |
Without this, glviewconvert (and thus glimagesink) will drop all overlay
composition metas.
|
|
|
|
|
|
|
|
|
|
| |
... instead of waiting for the first non-header buffer.
Also drop non-identification headers arriving after initialization or
before the identification header. We don't do anything with them and
they would just accumulate.
https://bugzilla.gnome.org/show_bug.cgi?id=796980
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The argument 0x0 is interpreted by the x86 compiler as a 32-bit int, but
it is consumed as a 64-bit uint causing a segmentation fault. We need to
explicit cast it to guint64 in order for the va_list to be built correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=797092
|
|
|
|
|
|
|
|
|
|
| |
On Windows, the ringbuffer thread function must have the "Pro Audio"
priority set, otherwise it sometimes doesn't get scheduled for
200-300ms, which will immediately cause an underrun unless you set
a very high latency-time and buffer-time.
This has no compile-time deps since it tries to load avrt.dll at
runtime to set the thread priority.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packet arrives
And clean up any old pending headers if we receive a new identification
header, or if we receive a new set of headers via caps.
Otherwise it might happen that we receive one or more header but not
all, and then afterwards all headers again, and libvorbis does not like
getting headers passed multiple times and would error out.
It only makes sense to pass the very latest headers to the decoder at
the time we can actually make use of them.
https://bugzilla.gnome.org/show_bug.cgi?id=796980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gst_gl_window_dispmanx_egl_set_window_handle() removes native window handle
(dispmanx element), regardless it was foreign window handle
(set via gst_video_overlay_set_window_handle()) or not.
This problem prevents glimagesink reusable.
(PAUSED -> READY -> PAUSED does not work)
This patch corrects it comparing the native window handle with foreign window
handle. This behavior is same as gst_gl_window_dispmanx_egl_close().
https://bugzilla.gnome.org/show_bug.cgi?id=785199
|
|
|
|
|
| |
Otherwise we might have arbitrary values set that are used later and can
cause undefined behaviour, as found by ossfuzz.
|
|
|
|
| |
gstglcolorscale.c(173): warning C4098: 'gst_gl_colorscale_gl_stop': 'void' function returning a value
|
|
|
|
| |
aggregator subclasses that can't convert
|
|
|
|
|
|
|
| |
configured yet
The default caps fixation code would select a rate of 1 for example,
which is not really ideal.
|
| |
|
|
|
|
|
|
|
|
|
| |
The queue between the audiotee and the audio chain wasn't properly added to the
bin, leading to streamsynchronizer locks on EOS. Reconfiguration of the
visualization chain wasn't working as expected either. It is now possible to
dynamically enable/disable the audio visualization support.
https://bugzilla.gnome.org/show_bug.cgi?id=796553
|
|
|
|
|
| |
Instead of considering every failed typefinding as an error, even in
case of e.g. GST_FLOW_FLUSHING.
|
|
|
|
|
|
| |
And don't consider FLUSHING an actual error, just stop in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=796883
|
|
|
|
|
| |
Fixup for 58ac815eae6ed468d1db60a54a1bd34d6324c28c. Floating references
are such a mess.
|
|
|
|
|
|
|
| |
properties
Introduced by fbef9220d3dc2f785081c4766901aab2ecfaed10. The code there
is only correct for elements we get from signals.
|