By design, unixfd is meant to be used for zero-copy and failing when the data is
not FD based memory is wanted to help debug pipelines. Though, there exists
cases, notably with RTP payloader and demuxers, where its not possible
to get all the data into FD memory through allocation queries.
To allow using unixfd for these cases, introduce a property on the unixfdsink
that enable copying the non FD data into freshly allocated memfd.
Co-authored-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8861>
Wrap dependencies add a ton of warnings with the latest GCC in Fedora
42. Squelch them by specifying that these dependencies are not
a part of the gstreamer project, and should be treated as system deps.
libsoup needs some porting work for the bump, and vorbis/lame are
already at their latest releases.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8753>
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>
Now when the buffered list is requested, the tolerance for merging two ranges
when there's a small gap between them is MAX(0.1sec, max frame duration * 2).
Previously it was hardcoded to 0.01sec. The specification suggests that it
could be something like the max frame duration * 2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Both operations now work on coded frame groups (GOPs). This simplifies queueing
of video data. There is rarely any point of dealing with individual video frames
when iterating in DTS order, it's most meaningful to decode or delete whole
coded frame groups at a time, so the sample map will now do that when iterating
by DTS. When iterating in PTS order, the existing behavior is preserved since
that is used for informational purposes, not media processing.
A new private boxed type for coded frame groups was added to provide each data
item to the source buffer. Another possible solution would be creation of a new
GstSample representing the whole group by merging all the samples in a group
into a single sample containing a GstBufferList.
Also, start time filtering was removed from the API since gst_iterator_filter()
can be used by callers to achieve the same result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
If the vulkan plugin was compiled against a newer version than the supported
vulkan runtime instance or device, then it was possible for format retrieval to
fail. Failure was due to unconditionally using newer extensions and features
without runtime checking them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
The API version exposed by a particular device can be completely different from
what is exported by the parent instance. Since Vulkan 1.1 it is also possible
to use newer device API than supported by the instance API version (with the
appropriate version checks).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
Before this patch, there could be duplicate payload types in offers that
have, within a media section, multiple codecs and RTX enabled:
```
m=video 9 UDP/TLS/RTP/SAVPF 96 97 97 <-- HAS DUPLICATES
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 transport-cc
a=rtpmap:97 H264/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 transport-cc
a=rtpmap:97 rtx/90000 <--------- PT IS DUPLICATE
a=fmtp:97 apt=96
```
Fix this by populating the media_mapping array with all media formats
rather than only the first one. The added test case reproduces the issue,
which fails without this patch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8259>
We get loads of warnings when parsing videos from users:
gsth264parser.c:1115:gst_h264_parser_parse_user_data_unregistered: No more remaining payload data to store
gsth264parse.c:646:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message
Those are raised because of unregistered SEI without user data.
The spec does not explicitly state that unregistered SEI needs to have
data and I suppose the UUID by itself can carry valuable information.
FFmpeg also parses and exposes such SEI so there is no reason for us no
too as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7931>
It creates a new structure for passing the codec quality structure at _start(),
where it will be filled. The quality level can be set or changed according
encoder limits.
Later the quality level will be set at _update_session_parameters() and at each
frame encoding. That's why it has to be set at _start().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
