Specification says:
"""
engineVersion is an unsigned integer variable containing the developer-supplied
version number of the engine used to create the application.
"""
Assuming the engine is GStreamer, it would be expected to set its version as
engine version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4243>
In the same spirit of libva-win32 elements this patch shows the driver of each
element in gst-inspect, giving more information to the user. This driver
description is parsed from vaQueryVendorString from mesa and intel drivers,
while copied as is for others. Also appends the render node for multi gpu
systems.
Fixes#2349
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4204>
Otherwise application would not be able to know matching element
for wanted device. Typical use case of the read-only device path
(DXGI Adapter LUID, CUDA device index, etc) property is that
application enumerates physical devices and then selects matching
GStreamer element (in null state) via device path property.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4220>
H.265 NAL always have 2 bytes of headers. Unlike the H.264 parser, this parser
will simply return that there is NO_NAL if some of these bytes are missing.
This is then properly special cased by parsers and decoders. Add a test to
ensure we don't break this in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The appropriate return value for incomplete NAL header should be
GST_H264_PARSER_NO_NAL_END. This tells the parser element to
gather more data. Previously, it would assume the NAL is corrupted
and would drop the data, potentially causing stream corruption.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
Previously, reassigning loop index l in nicestream.c
could cause a segfault if l->data was null, as it could
reassign l to a null variable, triggering the loop
postassignment l->next, which then segfaults due to
l now being null. It is instead moved into the loop.
_delete_transport already performs the reassignment
inline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4192>
In webrtc_data_channel_send functions, both data and string,
an early return on a non-open datachannel caused it to leak
the buffer used for pushing to appsrc, meaning any buffer
sent after leaving the open state was leaked in full.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4191>
If the input is not a DMABuf, attempt to copy into a DRM Dumb
buffer and import it has a DMABuf. This will offload the
compositor from actually doing this copy (needed to handle SHM)
and may allow the software decoded stream to be rendered to
an HW layer, or even reach through some better accelerated
GL import path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
This allow simplifying the GstVideoInfo handling in the sinks. Instead
of having to update a video info for the import, the sink can simply pass the
video info associated with the caps and rely on the VideoMeta in the GstBuffer
to obtain the appropriate offset and stride.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
As we don't render into the widget directly, there is no "initial" draw
happening. As a side effect, the internal aspect ratio adapted display
width/height is never initialize leading to assertions when handling navigation
events.
gst_video_center_rect: assertion 'src->h != 0' failed
Simply queue a redraw after setting the widget format in order to fix the issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
gstcudaloader.cpp defines GST_DEBUG_CATEGORY (gst_cudaloader_debug);
but it wasn't initializing it anywhere.
This caused the following error to be logged by gst-plugin-scanner when
libcuda.so.1/nvcuda.dll couldn't be loaded, e.g. in systems without
CUDA:
(gst-plugin-scanner:39618): GStreamer-CRITICAL **: 14:40:22.346:
gst_debug_log_full_valist: assertion 'category != NULL' failed
This patch fixes the bug by initializing the category in
gst_cuda_load_library_once_func() before any logging occurs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4154>
These days you're can use minFrameDuration and maxFrameDuration which
are CMTime with fractional values. That way we don't need to convert
between double and fractions in a really weird way.
This fixes really odd fractional values exposed in caps, like:
2000000/76923, 1000000/37037, 5000000/178571, 10000000/344827, 10000000/333333
Which are actually just 26/1, 27/1, 28/1, 29/1, 30/1
We can also delete a lot of outdated code for iOS versions older than
7.0 by using newer APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4134>
Removing a meta from a buffer means one doesn't have access to it
anymore. Instead use the already reffed composition directly.
Fixes a use-after-free in the following pipeline:
... ! vulkanupload ! timeoverlay ! vulkanoverlaycompositor ! ...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4143>
As specified in EIA/CEA-608-B section 8.4:
When closed captioning is used on line 21, field 2, it shall conform
to all of the applicable specifications and recommended practices as
defined for field 1 services with the following differences:
a) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 14h, 20h to 14h, 2Fh in field 1, shall be replaced
with 15h, 20h to 15h, 2Fh when used in field 2.
b) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 1Ch, 20h to 1Ch, 2Fh in field 1, shall be replaced
with 1Dh, 20h to 1Dh, 2Fh when used in field 2.
This means simply switching the "field" field in the caps isn't enough for
converting raw 608 from one field to another, some control codes also
need to be amended.
+ Adds simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4126>
GstBufferPool implementation was referenced for this GstD3D11PoolAllocator,
for example GstAtomicQueue, various atomic operations, and GstPoll ones.
However, such combination seems to be almost pointless
since gst_poll_{read,write}_control() takes mutex and also
GstPoll uses Win32 event handle internally.
Use simple SRWLOCK and CONDITION_VARIABLE instead, and don't make things
complicated/inefficient.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2887>
The code wants to prepend one byte to every byte pair. It correctly did
so by working backwards pair-wise, but then didn't work backwards
instead of each individual pair / future triplet, overwriting
information before attempting to read it.
The code also failed to update the len pointer after prepending.
This fixes both issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4100>
Removing sockets from the epoll for cancellation is unreliable and might
not be thread-safe. Rather, have SRT watch a FD from the cancellable if
available. Keep the cancellable cancelled while we're not open.
Use the regular single-socket `sock` and `poll_id` fields for the
listening thread instead of duplicating them.
Before polling we need to check the socket state. SRT closes broken
sockets by itself and when the epoll contains our cancellation FD it can
no longer be empty, which was an error before.
Treat more failures in the read and write operations as an opportunity
to try a reconnect.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
Seems that SRT can remove the socket from the poll by itself when the
connection gets closed. Consider this an error condition and ensure we
only "abort successfully" when we're actually trying to unlock.
Needs more investigation but this is enough to prevent the element from
getting stuck not reporting an error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
