.. in decoders.
Inline session parameters allows to not create session parameters handlers for
every new stream parameters (such as SPS and PPS for H.264, for example), but
instead to pass them as a chained structure in the decoding main structure. This
is completely align with GStreamer decoder base classes.
Even that the previous approach is kept, if the devices doesn't support video
maintenance2, it shows a lot of validation errors.
Also it was required to add another parameter when enabling extension to verify
if the extension is linked with a device feature and if it is enabled.
Bump Vulkan API (and driver version for both decoders and encoders) to 1.4.306
Also bumped the ABI_CHECK_TAG because the CI finally catches up with the vulkan
video symbols that are not exposed by a public header (tough they are binary
public).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9585>
The validation complained with
VUID-VkImageCreateInfo-usage-requiredbitmask]:
vkCreateImage(): pCreateInfo->usage is zero.
This patch force to use the internal defaults in vkimagebufferpool if no usage
is defined.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9544>
If mpegtsmux receives the same caps again, it wrongly claims the stream
type changed:
error: Stream type change from 06 to 8f not supported
This adds a unit test that demonstrate the issue in the very hacky way.
I have seen this happening with the below pipeline when upstream caps
changes. Since the caps filter fixates the caps received by opusenc and
mpegtsmux, the stream type cannot change.
...
! audioconvert
! audio/x-raw,format=S16LE,channels=2,rate=48000
! opusenc bitrate=128000
! mpegtsmux
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9430>
Make it work a little more like RTP. Have the source interact with the
clock and set the capture time on each packet. Then the other elements
can use that to do adjustments. Since AVTP is always very low latency,
it can be assumed that the gPTP clock at the packet reception is very
close to the sending time, never more than 2 seconds off, so the
timestamps can be compared directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9412>
Change so that the handling of NAL unit that can't be parsed when using
AU alignment is the same as when using NAL alignment, ie drop the data
if it can't be parsed.
If the AU contains more than one NAL unit any correctly parsed NAL unit
in the AU is kept.
Fixes#4436
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8976>
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>
