If we end up with GST_CLOCK_TIME_NONE as running time for an RTP packet
then this can't be used for bitrate estimation, and also not for
constructing the next RTCP SR. Both would end up with completely wrong
values, and an RTCP SR with wrong values can easily break
synchronization in receivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5329>
This was easy to trigger when testing with e.g. vtenc ! vtdec ! glimagesink and closing the sink via window button,
causing GST_FLOW_ERROR to be received by the output loop, stopping it with the queue still full. This made the
enqueue_buffer() callback to lock waiting for space in our queue, while handle_frame() was waiting for the internal
VideoToolbox queue to free up, so that VTCompressionSessionEncodeFrame could finish. As the output loop was not
running, both functions waited forever.
Fixed by 1) immediately emptying our queue when GST_FLOW_ERROR is received (like we already did with _FLUSHING)
and 2) unconditionally setting the flushing flag in finish_encoding() when it sees the output loop stopped because
of GST_FLOW_ERROR, so that enqueue_buffer() will immediately discard any new frames coming out of VideoToolbox.
Both of those make sure we never run into the both-queues-full scenario.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5303>
As a short-term solution before full d3d12 rendering feature,
copy decoded d3d12 texture to shared d3d11 texture in order to use
existing various d3d11 implementations such as conversion, resizing,
and videosink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5356>
There is no need to use DRM dumb pool if buffer to
render is already a DMABuf, just import it and render it.
This fixes a DMAbuf memory leakage when waylandsink downstream
element exports DMABuf while waylandsink is configured to be
DMABuf exporter (drm-device=/drv/dri/card0):
gst-launch-1.0 v4l2src io-mode=4 ! gtkwaylandsink drm-device=/dev/dri/card0
leakage identfied with command:
watch "cat /sys/kernel/debug/dma_buf/bufinfo | grep attached "
Fixes#2729
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5350>
There is no need to use DRM dumb pool if buffer to
render is already a DMABuf, just import it and render it.
This fixes a DMAbuf memory leakage when waylandsink downstream
element exports DMABuf while waylandsink is configured to be
DMABuf exporter (drm-device=/drv/dri/card0):
gst-launch-1.0 v4l2src io-mode=4 ! waylandsink drm-device=/dev/dri/card0
leakage identfied with command:
watch "cat /sys/kernel/debug/dma_buf/bufinfo | grep attached "
Fixes#2729
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5350>
Don't update info's size with the VA image reported data size for single plane
images, since drivers might allocate bigger space than the strictly required to
store the image, but when we dump the buffer as is (using filesink, for example)
the produced stream is corrupted. For multi-plane images video meta is required
to read/write them.
We updated info's size because gstreamer-vaapi did it too, but the reason to
update it there was for uploading and rendering surfaces (commit c698a015).
Furthermore, this patch adds an error message if the allocated data size for the
image by the driver is lesser than the expected because it would be a buggy
driver.
Fixes: #2959
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5308>
Even if decoder is negotiated with CUDA memory feature, if downstream
proposed no buffer pool, assume that the pool size is unknown.
And disable zero-copy if there's no more free output surface.
Or, in case of reverse playback, always copy frames.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5338>
Even if the segmentation feature value is not updated,
the parsed "segmentation_update_map" and "segmentation_temporal_update"
values should not be cleared as it's referenced during lower
level bitstream parsing. Also, don't use assert() in parser
unless it's clearly impossible condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5334>
If DPB is full already, GstH265Decoder::new_picture() might fail if
subclass uses fixed size picture pool and its size is equal to the DPB
size. Call the new_picture() after DPB is cleared in gst_h265_decoder_dpb_init()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5333>
Issue is that when amc was producing a codec-data buffer, a
GstVideoCodecFrame was being popped off the internal queue. This meant
that the codec-data was being associated with the first input frame and
the second (first encoded buffer) output buffer with the second input
frame. At the end (assuming one input produces one output which seems
to hold in my testing and how the encoder is currently implemented)
there would be an input frame missing and would be pushed without any
timing information. This would lead to e.g. muxers rejecting the buffer
without PTS and failing to mux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5330>
The timestamp offset can be negative, and it can be a bigger negative
number than the latency introduced by the rtpjitterbuffer so the overall
timeout offset can be negative.
Using the negative offset for calculating how many packets can still
arrive in time when encountering a lost packet in an equidistant stream
would then overflow and instead of considering fewer packets lost a lot
more packets are considered lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5296>
The GST_VIDEO_FORMAT_Y410, GST_VIDEO_FORMAT_Y412_LE and GST_VIDEO_FORMAT_Y412_BE
formats in fact are packed formats, which have just 1 plane. But we have special
setting for them rather than using get_single_planar_format_gl_swizzle_order().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5314>
As we don't have any mapping from YUV formats + modifiers to an equivalent
emulated format (e.g. NV12 + modifier -> R8+modifier/RG88+modifier), do no
allow these formats to be used with the indirect DMABuf uploader.
Fixes#2942
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5270>
gst_video_info_set_interlaced_format() can return an error if the
width/height causes integer overflow. Handle this case, so that we can
fail cleanly. This has been experienced while testing an in-progress
driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5286>
Some drivers will push an buffer flagged LAST but empty. In decoder
case, this results in an "producing too many buffer" warning, even
though the result is entirely correct. Detect this case in order to
signal EOS earlier and avoid this warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5286>
This is consistent with the librtmp-based old rtmp plugin and ffmpeg.
While some servers require a valid flash-version, others are failing
with a too long or any flash-version at all.
By changing to the same default as in the old plugin and in ffmpeg,
GStreamer will at least behave the same and will work and fail with the
same servers without setting a flash-version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5293>
The same is done in the set_property function. This was noticed when attempting
to dump a pipeline containing glsinkbin sink=gtk4paintablesink to dot format.
Critical warnings were raised due to the missing force-aspect-ratio property on
that sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5311>
It is similar to NV12 but has 10bits per channel instead of 8.
As it is supported by many modern GPUs, VA-API and an increasing
number of Wayland compositors, let's support it as well.
Also bump the required libdrm version accordingly and add a temporary
define for the WL_SHM format.
Tested with Weston, Mutter and Sway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5275>
unlock_stop() is expected to be run while the streaming thread is idle. To
guaranty this is the case, we should take the streamlock, but its not
possible to take this lock during state transitions from PAUSED to
PLAYING as the wait function that we want to terminate is holding it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
After a create() call, which may have returned FLUSHING or a filled buffer,
if it possible that we detect that we are now in pause. As live sourced
don't produce data in pause, drop the buffer is any and later retry creating
a buffer. This will ensure that we resume from pause while avoiding displaying
ancient frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
When the pipeline goes from Playing to Paused, this change will invoke
unlock in the derived class. When the pipeline goes from Paused to
Playing, this change will invoke unlock_stop in the derived class.
This feature was removed in commit 523de1a9 and is now being restored.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
Fixes regression introduced in ba61160d6c,
where running check tests with gst-validate-launcher -f would trigger
this exception:
AttributeError: 'GstCheckTest' object has no attribute 'reports'.
Did you mean: 'reporter'?
The member `reports` is meant to be just part of GstValidateTest, but
not other subclasses, even though a usage is still found in the base
class GstTest in the method test_end().
This patch introduces an override of the methods copy() and test_end()
in GstValidateTest so that `reports` is copied and cleared respectively,
but only for validate tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5281>
This is to fix an infinitely blocked upstream streaming thread if
* upstream has fixed-size buffer pool, some H/W decoders for example
* downstream returned flow error without releasing buffer
When the fixed-size buffer pool hits its configured max-buffers and
also downstream of queue returned flow error without releasing corresponding
buffer, upstream has no chance to run the next processing loop
because it will be blocked by acquire_buffer(), and therefore
downstream flow will not be propagated to upstream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5023>
Old versions of mesa doesn't support VASurfaceAttribDRMFormatModifiers. To
solve it, by just ignoring the modifiers assuming that linear is accepted and
produced, the creation of frames will be tried again without that attribute.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5256>
This patch removes the code duplication of input buffer importation, in all the
va elements that import video frames. It defines a synthetic object whose
members are required to create a new input buffer and do the importation of the
upstream buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5257>
Fixes a potential GPU stall if an immediately freed texture/buffer is
attempted to be reused immediately by the CPU, e.g. when uploading.
Problematic scenario is this:
1. element does GPU processing reading from texture
2. frees the buffer back to the pool
3. pool acquire returns the just released buffer
4. GPU processing then has to wait for the previous GPU operation to
complete causing a stall
If there was a reliable way to know whether a buffer had been finished
with across all GPU drivers, we would use it. However as that does not
exist, this workaround is to keep the released buffer unusable until the
next released buffer.
This is the same approach as is used in the qml (Qt5) elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5144>
Setting the surface source rectangle has been omitted so far. As a side effect
surface created with padded width/height are being scaled down. Fix this using
the viewporter source rectangle configuration. This can later be enhanced
to support crop meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5259>
When we consider the DMA kind caps as input, the input_state->info
only contains the video format of GST_VIDEO_FORMAT_DMA_DRM, which
is not enough for va plugins. The new info in base encoder contains
the correct video info after the DMA caps parsing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5189>
Since d3d11convert and its variant elements does not enable basetransform's
passthrough, passthrough allocation query needs to be handled
manually in order to respect downstream element's min/max buffer
requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5255>
When using `gst_sdp_media_set_media_from_caps` on `application/x-rtp` caps
without `clock-rate` it wrongly reports missing payload type even if `payload`
is present in the caps.
This seems to be a copy&paste error from the error message for missing payload
type.
When using payload=10, both `clock-rate` and some other media properties are
defined by the RTP standard so I was wondering whether I could omit `clock-rate`
and was confused about the error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5250>
* Library versioning should not be used for plugins since it will add
-{version}.dll suffix (and versioned libraries on Linux with symlink).
Then the library file name and plugin init function name mismatch
will result in blacklisted plugin.
* Don't define BUILDING_GST_CODECS, makes no sense
* Don't define G_LOG_DOMAIN, which should be used only for libraries,
not plugins
* Depends on gstcodecparsers libary, not gstcodecs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5249>
This page has been only sporadically updated for a decade, and it is
unlikely to be updated properly anytime soon. Update the top half, and
add a note about the tutorial section being out of date.
The trigger for this was a question on the mailing list about Windows
11 support, since it's not listed in the supported platforms list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5239>
