The element should allocate GstFdMemory large enough to fit incoming
memory's size plus its potential offset.
Fixes "gst_memory_resize: assertion 'size + mem->offset + offset <=
mem->maxsize' failed".
Fixes an issue reproducible on Raspberry Pi 4 that results in a garbled
image on the receiver's end:
gst-launch-1.0 libcamerasrc ! unixfdsink socket-path=/tmp/socket
gst-launch-1.0 unixfdsrc socket-path=/tmp/socket ! autovideosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8025>
This helps debug cases when the remote is offerer and m-line does not match with already existing transceivers.
In this case, it will create new ones with sendrecv direction without any warning.
Similar with code from _create_answer_task
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8735>
The complete handling on the control interface is currently dead.
We return with EOPNOTSUPP for the caller to know that a response
to such requests is not valid. The host however may ask
control interface why these control requests were not available.
For this the UVC_VC_REQUEST_ERROR_CODE_CONTROL is used. As an overall
exception for the control interface we just always return 0x06 as
an response which is representing "not implemented".
This patch is a necessary feature to properly pass the UVC Functionality
Test of the USB3CV Compliance Software.
Fixes: 69c17461392d ('uvcgadget: Properly implement GET_INFO control responses')
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7524>
For some third-party devices macOS sometimes reports silly framerates,
like 750003/6250 instead of 120/1. To avoid users having to exactly
pecify those values, we instead report the closest reasonable value in
caps. If it ends up being chosen, the additional logic in
setDeviceCaps() will reverse that process and pass the actual supported
value back to AVF, as most often the rounding causes us to fall just
outside the accepted threshold.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8745>
Depending on the system load the test 'video_capture_with_tags' may
fail or not. Reason is that 'videotestsrc' may emit a buffer before
the final caps negotiation on the recording pipeline has happened
after dynamic linking.
In that case there would be a caps change and because videorate does
no longer drop old buffers and caps on change but pushes duplicates if
required qtmux will notice a caps change and fail to link.
The problem is a synchronization problem in 'camerabin' which became
obvious with the changed behaviour of 'videorate'.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
This happens on F42 with the JPEG decoders for some reason and trying to
actually use them with any resolution simply gives a "resolution not supported"
error.
A minimum of 64 is correctly reported though and trying to create caps with an
int range of [64, 0] gives critical warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8736>
If the caller passed in "audio_%u" instead of a concrete pad name into
gst_element_request_pad_simple() then the pad name will be NULL. In that case
use the pad template name for requesting the pad from splitmuxsink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8697>
`gst/analytics/analytics.h` includes `gst/analytics/gstanalyticssegmentationmtd.h`,
which in turn `gst/video/video-info.h` but `gst-video-1.0` was only listed
in `Requires.private` field of `gst-analytics-1.0.pc`.
This would cause projects linking against `gst-analytics-1.0.pc` to fail to find
the headers when using alternative interpretation of pkg-config specification
that only considers private dependencies for include path during static builds,
such as the case e.g. on Nix.
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/28
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8661>
The position is no longer duplicated across each pad and pad's segment. The
position is now only updated if it changes in the direction of playback so that
quickly repeated forward seeks do not cause the stream to seek from 0.
Reverse playback is expressly disallowed and an unnecessary extra flush of track
when seeking was removed.
A background task was added to periodically check on the current position and
the media source's buffering levels to keep the ready state up-to-date. The
source buffer no longer needs to trigger this update, it will happen whenever
the element state is READY or higher.
Finally, added proper error reporting when failing to push a buffer and improved
debug logging.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
