Currently the uvcsink is only capable to run in an application
that is handling the state transitions of the pipeline properly
by checking on streaming event from the uvcsink.
This code is improving the element by adding an fakesink to
consume possible videostream flow in case the pipeline state
is not changing on hosts streamoff.
This is helpfull when using local gst-launch pipelines where
the streaming event is not monitored to change the pipelines
state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304>
This patch adds an element to stream video data to an uvc video gadget.
The element handles the uvc events STREAMON, STREAMOFF, SETUP and DATA.
to start, stop and configure the video buffer flow by the use of pad
probes. It works with linux kernels of versions higher than v6.1.
The element makes use of the v4l2sink proxy property v4l2sink::device
to locate the corresponding device to parse the configfs for additional
data.
The code in uvc.c is basically derived from /lib/uvc.c in
https://git.ideasonboard.org/uvc-gadget.git.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304>
Updated API usage appropriately, and now we have a versioned package to
track breaking vs. non-breaking updates.
Deprecates a number of properties (and we have to plug in our own values
for related enums which are now gone):
* echo-suprression-level
* experimental-agc
* extended-filter
* delay-agnostic
* voice-detection-frame-size-ms
* voice-detection-likelihood
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2943>
self->eos was never reset after streamsynchronizer has sent EOS
(except on explicit flush or switching back to PAUSED).
As a result, synchronization was broken if new streams were pushed later
as gst_stream_synchronizer_wait() does not wait if self->eos is set.
Fix this by reseting self->eos on STREAM_START as that means a new
stream is being sent upstream and so a new EOS will follow later on.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4749>
In the case of a gstreamer-full target type to static,
the GST_STATIC_COMPILATION is necessary on Windows to avoid
a different mangling from the external project using the
gstreamer-full libraries (ie dllimport).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
Allow a project to use gstreamer-full as a static library
and link to create a binary without dependencies.
Introduce the option 'gst-full-target-type' to
select the build type, dynamic(default) or static.
In gstreamer-full/static build configuration gstreamer (gst.c)
needs the symbol gst_init_static_plugins which is defined
in gstreamer-full.
All the tests and examples are linking with gstreamer but the
symbol gst_init_static_plugins is only defined in the gstreamer-full
library. gstreamer-full can not be built first as it needs to know what plugins
will be built.
One option would be to build all the examples and tests after
gstreamer-full as the tools.
Disable tools build in subprojects too as it will be built at the end of
build process.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
According to the documentation this should never happen but apparently
does under certain circumstances. As the sockets are set non-blocking,
trying to read from them regardless should not cause any problems.
In all cases that were observed so far, the socket in question actually
has a packet queued up for reading.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4748>
This patch adds gst_egl_image_from_dmabuf_direct_target_with_dma_drm() and
add gst_egl_image_from_dmabuf_with_dma_drm() functions
New function gst_egl_image_from_dmabuf_direct_target_with_dma_drm(), where
gst_egl_image_from_dmabuf_direct_target() is a specialization of the first.
And gst_egl_image_from_dmabuf() is a specialization of new function
gst_egl_image_from_dmabuf_with_dma_drm()
Co-authored-by: Victor Jaquez <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4680>
It internally uses gst_gl_context_egl_get_dma_formats() instead of fetching
modifiers by itself.
Thus gst_egl_image_check_dmabuf_direct() is a decorator of this new function.
Co-authored-by: He Junyan <junyan.he@intel.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4680>
By calling the internal function gst_gl_context_egl_fetch_dma_formats() the an
array of structures holding a DMA fourcc format and its modifiers (another array of
structure holing modifier and if it's external only) will be stored.
Users would call gst_gl_context_egl_get_format_modifiers() to get the array of
modifiers of a specific DMA fourcc format.
Co-authored-by: He Junyan <junyan.he@intel.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4680>
The `switch (n_rear)` supports up to 5 rear channels, but our channel
set only had space for 3. Size the set properly to fix this.
This didn't actually cause any memory unsafety as `PUSH_CHAN` would stop
incrementing `n_rear` if the channel set is already full.
Thanks to @alatiera for noticing this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4712>
Since c0bf793c05 ("flvmux: Set PTS based on
running time") the timestamp of the output buffer is already in running
time. So using that for 'srcpad->segment.position' does not work correctly
because gst_aggregator_simple_get_next_time() will convert it again with
gst_segment_to_running_time().
This means that the timestamp returned by
gst_aggregator_simple_get_next_time() may be incorrect. For example, if
flvmux is added to a already runinng pipeline then the timestamp is too
small and gst_aggregator_wait_and_check() returns immediately. As a result,
buffers may be muxed in the wrong order.
To fix this, use the PTS of the incoming buffer instead of the outgoing
buffer. Also add the duration as get_next_time() is supposed to return the
timestamp of the next buffer, not the current one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4701>
