Add Windows Graphics Capture (WGC) API based screen capture mode.
The conditions where this mode is used:
* Explicitly requested by user (capture-api property)
* To capture specific window
* When DXGI desktop duplication API does not work on hybrid graphics systems
(e.g., multi-gpu laptop)
Full features of this implementation require Windows 11. And Windows 11
SDK is required to build this feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3144>
When the output alignment is smaller than the input alignment, for
example, When the output alignment is "FRAME" and the parse is likely
connecting to a decoder, the current PTS setting for AV1 frames inside
a TU is not very correct.
For example, a TU may begin with non-displayed frames and end with a
displayed frame. The current way will assign the PTS to the first
non-displayed frame, which is a decode-only frame and the PTS will be
discarded in the video decoder. While the last displayed frame has
invalid PTS, and so the video decoder needs to guess its PTS based on
the frame rate and previous frame's PTS. This is not a decent and
robust way. And more important, when the previous frames provide DTS,
the video decoder will also guess the PTS based on the previous frames'
DTS and trigger the warning like:
gstvideodecoder.c:3147:gst_video_decoder_prepare_finish_frame: \
<vavp9dec0> decreasing timestame
It sets the reordered_output and makes the decoder in free run mode.
We should correct the PTS for a TU, let the non-displayed frames have
no PTS while set the correct PTS to the displayed one. Also, when the
AV1 stream has multi spatial layers, there are more than one displayed
frames inside one TU with the same PTS.
Note: If the input alignment is not TU aligned, we can not know the
exact PTS of this TU, and so we just clear the PTS of the decode only
frame and leave others unchanged.
We also correct all the PTS if the output is OBU aligned. All their
PTS and DTS are set to the input buffer's PTS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182>
When the incoming data has big alignment than the output, we do not need to
call finish_frame() and exit the current handle_frame() for each splitted
frame. We can push them all at one shot with in one handle_frame(), whcih
may improve the performance and can help us to find the edge of TU.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182>
Adding loopback capture mode for specified PID.
Note that this feature requires Windows 10 build 20348
(Windows 11/Windows Server 2022 or later),
and any process loopback related properties will not be exposed
if OS does not support it.
Example launch lines:
* wasapi2src loopback-mode=include-process-tree loopback-target-pid=<PID>
Captures audio generated by an application (specified by PID)
and its child process
* wasapi2src loopback-mode=exclude-process-tree loopback-target-pid=<PID>
Captures desktop audio excluding PID and its child process
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1278
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3195>
If there is an error while connecting, the streaming task will be stopped, and
is_running() will be false, causing a GST_FLOW_FLUSHING to be returned. Instead,
we perform the error check (!self->connection) first, to return an error if
that's what occured.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3189>
When the alignment is "FRAME" and the parse is likely connecting to
a decoder, the current PTS setting for VP9 frames inside a super
frame is not very correct.
For example, the super frame may begin with non-displayed frames and
end with a displayed frame. The current way will assign the PTS to
the first non-displayed frame, which is a decode-only frame and the
PTS will be discarded in the video decoder. While the last displayed
frame has invalid PTS, and so the video decoder needs to guess its
PTS based on the frame rate and previous frame's PTS. This is not a
decent and robust way. And more important, when the previous frames
provide DTS, the video decoder will also guess the PTS based on the
previous frames' DTS and trigger the warning like:
gstvideodecoder.c:3147:gst_video_decoder_prepare_finish_frame: \
<vavp9dec0> decreasing timestame
It sets the reordered_output and makes the decoder in free run mode.
We should correct the PTS for a super frame, let the non-displayed
frames have no PTS while set the correct PTS to the displayed one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3155>
Apparently we cannot start sending messages from another datachannel
before the previous message was completely sent. usrsctplib will
complain about being locked on another stream id and set
errno=EINVAL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2454>
The order of the devices iterator from the SDK is undefined and can
randomly change.
Keep the device-number property for backwards compatibility and
simplicity but prefer the persistent-id property and also use it for the
device provider implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3078>
GstDXGIGetDebugInterface() is unused when targeting UWP. We directly
call DXGIGetDebugInterface1() in that case.
Fixes build failure:
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): error C2440: '=': cannot convert from 'HRESULT (__cdecl *)(UINT,const IID &,void **)' to 'DXGIGetDebugInterface_t'
../gst-libs/gst/d3d11/gstd3d11device.cpp(271): note: This conversion requires a reinterpret_cast, a C-style cast or function-style cast
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3118>
According to W3C
specification (https://w3c.github.io/webrtc-pc/#datachannel-send) we
should return InvalidStateError exception when trying to send when the
channel is not open. In the world of C/glib/gstreamer we don't have
exceptions but have to rely on gboolean/GError instead. Introducing
these calls for a change in function signature of the action signals
used to send data on the datachannel. Changing the signature of the
existing "send-string" and "send-data" signals would mean an immediate
breaking change so instead we deprecate them. Furthermore, there is no
way to express GError** as an argument to an action signal in a way
that fits language bindings (pointer-to-pointer simply does not work)
and we have to use regular functions instead.
Therefore we introduce gst_webrtc_data_channel_send_data_full() and
gst_webrtc_data_channel_send_string_full() while deprecating the old
functions and corresponding signals.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1958>
Currently if the user is not able to access the devices under /dev/media*,
either due to no media devices present on the system or simply no permission
to access the device, v4l2codecs initialises with no features or debug messages.
Since calling `GST_DEBUG="v4l2*:7" gst-inspect-1.0 v4l2codecs` is a typical way
to diagnose why element(s) failed to enumerate, we should be more verbose here
when the user is not able to access any /dev/media* device. So print a simple
debug message in this case to aid debugging.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3088>
Since commit a79a756b79 we could change to ignore-pcr automatically at 500ms
into a live stream when no PCR is seen by then. However the stream counting in
program change detection was wrongly considering ignore-pcr programs to have a
separate PCR PID, even though we are actually ignoring the PCR PID completely,
resulting in an erroneous program switch getting triggered from the different
stream count. This in turn would send an EOS and switch out the pads for what
actually is still the same program, while we intended to simply apply a
workaround for broken encoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3060>
Fixes warning with meson 0.62:
gst-plugins-bad| subprojects/gst-plugins-bad/meson.build:546: WARNING:
Project targets '>= 0.62' but uses feature deprecated since '0.62.0':
pkgconfig.generate variable for builtin directories. They will be
automatically included when referenced
and more.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3086>
Starting with Meson 0.62, meson automatically populates the variables
list in the pkgconfig file if you reference builtin directories in the
pkgconfig file (whether via a custom pkgconfig variable or elsewhere).
We need this, because ${prefix}/libexec is a hard-coded value which is
incorrect on, for example, Debian.
Bump requirement to 0.62, and remove version compares that retained
support for older Meson versions.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1245
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3061>
The AV1 support multi spatial layers within one TU with different
resolutions, and only the highest spatial layer need to be output.
For example, there are two spatial layer, base level is 800x600
and higher level is 1920x1080. We need to decode both because the
higher level needs base layer as reference, but we only need to output
1920x1080 frames here.
The current manner always renegotiates the caps once we detect the
current picture resolution changes, so we renegotiate again and
again between different layers. That's a big waste and has very
low performance. We now only do the renegotiation for the highest
output layer. For other non output layers, we just keep a internal
buffer pool which is big enough to handle the surface allocation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2382>
As SPEC says, when multi spatial layer exists, we should only output
one frame with the highest spatial id from each TU. We now store the
highest spatial layer information in the base class in order to let
the sub class handle different layers easily.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2382>
doesn't align on 20 millisecond frame size.
The AMR-WB codec imposes a fixed 20 millisecond frame size. In its current
form, the `voamrwbenc` plugin deals with this limitation by discarding any
audio at the end of the stream that falls short of 20 milliseconds. This patch
keeps the audio data, and appends silence to the end to preserve frame size
alignment.
The patch also adds tests to check for the updated behavior. I noticed that
tests weren't being built, so I changed the build to allow for building the
tests when the `tests` and `voamrwbenc` options are set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3027>
- Update the docker image we use, starting using the standard one adding
`gtk4-doc` as required by rust plugins
- Update the plugins_doc_caches as required, some more plugins are built
with the new image
- Install ninja from pip as the version from F31 is too old
- Avoid buildings all GSreamer plugins when building the doc as it takes
time and resources for no good reason
- Stop linking to `GInstanceInitFunc` as it is not present in latest GLib
documentation, leading to warnings in hotdoc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2954>
Handle d3d11 device context in set_context() method with
additional device compatibility check so that only NVIDIA GPU
associated d3d11 device can be configured in the element.
And clear old d3d11 device per set_info() for d3d11 device to be
updated as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3018>
... and fix d3d11 specific enum type name
GST_CUDA_HAS_D3D is a build time define which indicates whether
GstD3D11 library is available or not, but DirectX SDK headers
must be available on the build system already.
Expose Direct3D related symbols if the build target is Windows
(i.e., if G_OS_WIN32 is defined)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3018>
GLib made the unfortunate decision to prevent libgobject from ever being
unloaded, which means that now any library which registers a static type
can't ever be unloaded either (and any library that depends on those,
ad nauseam).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/778>
GstVA is not currently build by CI, because libva version is lower
than expected. So, the gstva library is not build, thus some symbols
aren't documented, breaking the documentation CI.
To move things forward, let's just remove temporarly the va plugins
from cache. While we decide on how to update the libva package in
the CI.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1025>
When picking an available payload type, we need to pick one that is
available across all media.
The previous code, when multiple media were present, looked at the first one,
noticed it had pt 96 as the media pt, then simply looked at the next media,
noticed it didn't, and decided 96 was available.
Instead, check if the pt is used by any of the media, if it is, decide
it is not available and go to the next pt. I'm fairly sure that was the
original intent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2984>
This avoids getting in a bunch of corner cases. We'd have to insert
a "rejected" line from the start as a place-holder to get around this,
but the rest of the code just becomes more complicated, so just
disallow it for now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2439>
If the buffer is not msdk_buffer, we can try to directly import the
attached memory (i.e. va mem and dmabuf mem) by applying the common
uitl function: import_to_msdk_function ().
Here add a flag "from_qdata" in GstMsdkSurface to handle the cropping case,
we should avoid updating the crop values when msdk_surface is from the
memory's qdata, because the crop info from this surface is the already
updated one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2498>
When input buffer is of dmabuf memory but not a msdk buffer (i.e., the
allocator is not msdk_allocator), then we can try to get fd of this mem,
create the corresponding va surface and wrap it as mfx surface.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2498>
We were checking possible bind flags for the DXGI format
of the source texture but that's never applied to
the destination texture desc.
Just use the already configured bind (and misc) flags of source texture
for the destination texture allocation without additional check.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2950>
Setting the content-type property shall override internally detected MIME
types, to make it possible to do as following example (where audio/basic to be
used prior to audio/x-mulaw):
gst-launch-1.0 ... ! mulawenc ! audio/x-mulaw,rate=8000,channels=1 !
curlhttpsink location=<url> content-type=audio/basic
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2732>
* Private header name is changed to gstd3d11-private.h to follow
naming convention
* Add Since mark everywhere
* Update member variable names to be consistent with the other
object implementations in this library
* Correct outdated documentation
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2945>
Current default G_MAXINT is not a correct value under any circumstances.
This creates an issue with screen capture, during which we currently do
not get any framerate info causing G_MAXINT to show up, where elements
downstream can possibly misbehave - for example, `vtenc` causes
a kernel panic.
Replace with 30/1 to avoid such scenarios.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2944>
The current handle_frame() does not return the real error that happens
in decode_scan and decode_frame, which makes the pipeline continue with
the error and may trigger asserting later.
We also return the error when decode_quant_table or decode_huffman_table
fails.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2938>
Add an example to show the usage of present singal.
In this example, a text overlay with alpha blended background
will be rendered on swapchain's backbuffer by using
Direct3D11, Direct2D, and DirectWrite APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2923>
The "present" signal will be emitted just before the
IDXGISwapChain::Present() call. The client can perform additional
GPU operation with given GstD3D11Device object and
ID3D11RenderTargetView handle. Or, the client can read back
the scene to be displayed on window using the signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2923>
This allows an application to provide their own opened DRM device
fd handle to kmssink. For example, an application can lease
multiple fd's from a DRM master to display on different CRTC
outputs at the same time with multiple kmssink instances.
Specifying the fd property is not allowed when driver-name
and/or bus-id properties are specified.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2807>
Without this change cleanup function for g_autoptr is not defined for
GstPlayMediaInfo, GstPlaySignalAdapter, GstPlayVideoRenderer,
GstPlayVideoOverlayVideoRenderer and GstPlayVisualization. Cleanup
function was defined in gstplay.h, but missing in other header files.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2888>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a play object created via g_object_new() is actually usable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2880>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a player object created via g_object_new() is actually usable.
In addition, also fix the video-renderer property so that reading it
returns an object of the correct type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2880>
This was showing up as a memory leak in GTK's
gstreamer media backend:
40 bytes in 1 blocks are definitely lost in loss record 18,487 of 40,868
at 0x484586F: malloc (vg_replace_malloc.c:381)
by 0x50D5278: g_malloc (gmem.c:125)
by 0x50EDBA5: g_slice_alloc (gslice.c:1072)
by 0x50EFBCC: g_slice_alloc0 (gslice.c:1098)
by 0x51F2F45: g_type_create_instance (gtype.c:1911)
by 0x51DAE37: g_object_new_internal (gobject.c:2011)
by 0x51DC080: g_object_new_with_properties (gobject.c:2181)
by 0x51DCB20: g_object_new (gobject.c:1821)
by 0x9855F86: UnknownInlinedFun (gstplayer-wrapped-video-renderer.c:109)
by 0x9855F86: gst_player_new (gstplayer.c:579)
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1374
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2875>
Radeon mesa gallium driver has a bug which adds P010_10LE sink caps
format. This patch removes formats which arent 420 chroma.
gst_caps_set_format_array() wasn't used because the fix traverse
several structures with potential different formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2844>
GLib's GRecMutex will allocate another heap memory for CRITICAL_SECTION
struct and g_rec_mutex_lock/g_rec_mutex_unlock use WIN32 APIs actually.
We don't need such intermediate function calls and redundant heap allocation.
Just call WIN32 APIs directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2845>
This is based on gtksink, but similar to waylandsink uses Wayland APIs
directly instead of rendering with Gtk/Cairo primitives.
Note that the long term plan is to move this into the existing extension
in `-good`, which requires the Wayland library to move the as well.
For this reason several files like `gstgtkutils.*` and `gtkgstbasewidget.*`
are straight copies and should be kept in sync.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1515>
With the 2.72 release, glib-networking developers have decided that
TLS certificate validation cannot be implemented correctly by them, so
they've deprecated it.
In a nutshell: a cert can have several validation errors, but there
are no guarantees that the TLS backend will return all those errors,
and things are made even more complicated by the fact that the list of
errors might refer to certs that are added for backwards-compat and
won't actually be used by the TLS library.
Our best option is to ignore the deprecation and pass the warning onto
users so they can make an appropriate security decision regarding
this.
We can't deprecate the tls-validation-flags property because it is
very useful when connecting to RTSP cameras that will never get
updates to fix certificate errors.
Relevant upstream merge requests / issues:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2214https://gitlab.gnome.org/GNOME/glib-networking/-/issues/179https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/193
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2494>
Depending on device feature level, d3d11 runtime can support
ID3D11Fence which is equivalent to ID3D12Fence.
Waiting using fence has performance-wise benefit over pulling
ID3D11Query status. If ID3D11Fence is not supported by device,
then ID3D11Query will be used instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2790>
It may happens that bitstream doesn't provided SPS in decoding order
(like in VPSSPSPPS_A_MainConcept_1 conformance test file).
To be sure that the decoder got the correct SPS parameters process
SPS just before start decoding the frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2575>
While possible defer computataion of pps and sps fields until
slice parsing since it may happens that bitstreams don't encoded
them in expected order.
A example weird ordered bitstreams is VPSSPSPPS_A_MainConcept_1
conformance test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2575>
The function g_array_sized_new() leaves the len to 0, but the slice
implementation assumes it would be set to 4. Sending multiple slices is
not yet support for H.264 as no driver needed it yet, but if that code
was to be used it would have overflowed as the array would never grow as
multiple 0 by 2 always results in 0.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1079>
We should move this functionality to gst-libs so that GstD3D11Converter
can be moved to gst-libs.
Another advantage is that applications can call our
HLSL compiler wrapper method without any worry about OS version
dependent system installed HLSL library.
Note that there are multiple HLSL compiler library versions
on Windows and system installed one would be OS version dependent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2760>
We need GStreamer elements to do the bandwidth estimation as this way
they can also control the pacing of the transmission flow as specified
in the [GCC] algorithm for example.
Bandwidth estimator element are placed right before the "RTPSession" as
an "rtp-aux-sender" element. This way they can use the "Transport-wide
Congestion Control" RTCP feedback messages through the "RTPTwcc" custom
events that are sent by the rtpsession.
Applications are responsible to react to the bandwidth estimator element
and set the encoder target bitrate etc... which means that we can not
pass an estimator as an element factory, so a signal as been chosen
instead.
[GCC]: https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2562>
There might be a sequence of event and buffer flow:
- Got stream-start/caps/segment events
- Got flush events
- And then buffers with a new segment event
In the above case, stream-start and caps event might not be reached to
peer proxysrc if peer proxysrc is not ready to receive them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1552>
... and don't use GstD3D11VideoProcessor. Now GstD3D11Converter will
be able to convert using videoprocessor, and texture upload is also supported by
GstD3D11Converter. All the noisy code can be removed therefore.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2697>
* Add videoprocessor feature to d3d11converter, in order to unifiy
conversion flow.
* Add convert_buffer() method to support automatic shader/videoprocessor
selection. The method also supports texture upload if input memory
cannot be used for conversion (e.g., system memory or so)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2697>
Adding nvautogpu{h264,h265}enc class which will accept upstream logical
GPU device object (GstCudaContext or GstD3D11Device) instead of
using pre-assigned GPU instance.
If upstream logical GPU device object is not NVENC compatible
(e.g., D3D11 device of non-NVIDIA GPU) or it's system memory,
then user specified "cuda-device-id" or "adapter-luid" property
will be used for GPU device selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2666>
GstCudaMemory supports CPU access via CUDA pinned host memory already
and it would show faster memory transfer performance between
GPU and CPU than copying from/to normal system memory.
If downstream supports video meta, we can passthrough CUDA memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2690>
Performs crop, scale, and color space conversion all in
a single render pipeline. Note that cropping related property is not
added in this element (which will make negotiation very complicated),
but user can configure videocrop element for crop meta to be attached
on each buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2678>
This example code demonstrates D3D11 device sharing between
application and GStreamer. Application can access texture
using appsink and it can be rendered on application's window without
any copy operation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2646>
Our Direct3D11 abstraction layer has been improved and
it gained good shape from API point of view.
Also, On Windows, GstD3D11 has various advantages over GstGL
in terms of compatibility/stability/feature/performance.
Note that WGL implementation is known to be buggy for some
drivers/vendors/scenario (that's a reason why Google implemented ANGLE).
Moreover, GstGL is not fully optimized for Windows unfortunately.
It's the time to open this interface to application developers
for various optimized processing using our Direct3D11
infrastructure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2646>
This patch adds general mechanism for handling specific hacks. In this
case for jpeg decoder in i965 driver, which cannot create surfaces
with fourcc specified.
From jpeg decoder to the allocator, which creates the surfaces,
there's a non-simple path: basedec pseudo-class adds a hacks guint32
which will be set by actual elements (vajpegdec, in this case) and
basedec will always set the hack to the allocator when the allocator
is instantiated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
Given the supported rt formats in a profile/entrypoint config it's
possible to know the supported JPEG colorspace and subsampling. This
patch adds this information in coded caps to a safer autoplugging
after jpegparser.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
This base class is intented for hardware accelerated decoders, but since
only VA uses it, it will be kept internally in va plugin.
It follows the same logic as the others video decoders in the library but.
as JPEG are independet images, there's no need to handle a DBP so no need
of a picture object. Instead a scan object is added with all the structures
required to decode the image (huffman and quant tables, mcus, etc.).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
Gallium drivers historically have reported strange dmabuf sizes, from always
zero to the whole frame (multiple fds). The simplest solution is to use lseek
SEEK_END to get the prime descriptor size.
Also the allocator raises a warning if both values differ in order to report
it to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2574>
