gst-plugins-bad merge requestshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests2023-10-10T20:56:27Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/783gdiscreencapsrc: capture a single window by name or id2023-10-10T20:56:27ZJoakim L. Giljegdiscreencapsrc: capture a single window by name or idThis adds support in gdiscreencapsrc for capturing a single window
similar to the ximagesrc plugin. The window can be referenced by
its window id/handle or by name.This adds support in gdiscreencapsrc for capturing a single window
similar to the ximagesrc plugin. The window can be referenced by
its window id/handle or by name.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2257d3d11: Add "sampler-filter" propoerty for user to be able to select filter me...2023-05-18T17:27:54ZSeungha Yangseungha@centricular.comd3d11: Add "sampler-filter" propoerty for user to be able to select filter method```
d3d11: Add "sampler-filter" propoerty for user to be able to select filter method
Add "sampler-filter" property to d3d11videosink,
d3d11convert, d3d11colorconvert, d3d11scale, and d3d11compositor
elements. It's simil...```
d3d11: Add "sampler-filter" propoerty for user to be able to select filter method
Add "sampler-filter" property to d3d11videosink,
d3d11convert, d3d11colorconvert, d3d11scale, and d3d11compositor
elements. It's similar to "method" property of videoscale.
This sampler-filter will be mapped to D3D11_FILTER value
which is used for filter method of sampler state.
Currently supported methods are
- Point (least expensive, worst visual quality)
- Bilinear
- Trilinear (default)
- Anisotropic (most expensive, best visual quality)
See also https://docs.microsoft.com/en-us/visualstudio/debugger/graphics/point-bilinear-trilinear-and-anisotropic-texture-filtering-variants?view=vs-2019
```
```
d3d11converter: Add config option for sampler filter mode selection
... and change default value from bilinear to trilinear, since
trilinear is default value mode of d3d11 sampler state
(see also https://docs.microsoft.com/en-us/windows/win32/api/d3d11/ns-d3d11-d3d11_sampler_desc#remarks)
and it's known to tend to work best for 2D
```
```
d3d11converter: Introduce config to be extensible
Add a config argument like that of GstVideoConverter so that
we can add more options without modifying existing methods
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2520Draft: d3d12: Add Direct3D12 H.264 video decoder2023-03-12T18:53:22ZSeungha Yangseungha@centricular.comDraft: d3d12: Add Direct3D12 H.264 video decoder... including minimum set of required implementations.
Note that d3dx12.h header is officially maintained by MS
but it's not a part of Windows SDK. So application needs to
copy it by hands. See also
https://docs.microsoft.com/en-us/windo...... including minimum set of required implementations.
Note that d3dx12.h header is officially maintained by MS
but it's not a part of Windows SDK. So application needs to
copy it by hands. See also
https://docs.microsoft.com/en-us/windows/win32/direct3d12/helper-structures-and-functions-for-d3d12
Another note is that since no other d3d12 element at the moment,
d3d12 decoder will output system memory by downloading every decoded
frame into system memory.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1882mediafoundation: Allow build in Windows irrespective of compiler.2022-12-19T12:08:41ZBiswapriyo Nathmediafoundation: Allow build in Windows irrespective of compiler.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2181Draft: wasapi2: Add support for Win32 only build2022-09-13T16:48:09ZSeungha Yangseungha@centricular.comDraft: wasapi2: Add support for Win32 only buildThe only difference between Win32 and WinRT (including UWP) is
device enumeration and activation. Split that part for Win32 and WinRT
so that wasapi2 plugin can support old OS (e.g., Windows 7) and
MinGW build as well.
In case that both...The only difference between Win32 and WinRT (including UWP) is
device enumeration and activation. Split that part for Win32 and WinRT
so that wasapi2 plugin can support old OS (e.g., Windows 7) and
MinGW build as well.
In case that both Win32 and WinRT are available, user can select
target implementation via "GST_USE_WASAPI2_WINRT_CLIENT" env var,
which is conceptually equivalent to "GST_USE_MF_WINRT_CAPTURE"
env of MediaFoundation plugin.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2382d3d11videosink: Some fixes for running in GstVideoOverlay mode2022-06-27T19:57:23ZPhilipp Trommlerd3d11videosink: Some fixes for running in GstVideoOverlay modeWhile trying to embed multiple `GstD3D11VideoSink`s as `GstVideoOverlay`s into our GTK4 application, we've stumbled upon some issues that I'm trying to resolve with the attached patches. Namely these are:
* Resizing of the overlays via ...While trying to embed multiple `GstD3D11VideoSink`s as `GstVideoOverlay`s into our GTK4 application, we've stumbled upon some issues that I'm trying to resolve with the attached patches. Namely these are:
* Resizing of the overlays via `gst_video_overlay_set_render_rectangle` did not work
* Creating multiple overlays in the same top level window has led to the original window procedure being irrecoverably lost
* Additionally, when creating multiple overlays, only one would behave normally
I've worked on these patches on top of `1.18.4` but also tested them on top of `1.19.1` (both GStreamer itself as well es gst-plugins-bad). Testing was done with our GTK application and (to ensure the normal use-case wasn't accidentally broken) with the simple pipeline
gst-launch-1.0 videotestsrc ! d3d11videosink
on Windows 10. I could reproduce the issues without and the fixes with my patches on both versions.
This is my first time working on both GStreamer plugins and the WIN32-API so it's well possible I've missed something, I'm especially unsure about that dead code removal. In that case I'm happy for any feedback and will adjust my patches accordingly.
Regarding the failed pipeline: I guess the issues are not in my code.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2080d3d11: Rework GstD3D11Memory API2022-06-27T19:52:24ZSeungha Yangseungha@centricular.comd3d11: Rework GstD3D11Memory API```
d3d11: Rework GstD3D11Memory API
Now resource view getter methods will provide strong reference
to each resource, so caller should release returned resources.
Another change is that caller MUST map GstD3D11Memory
...```
d3d11: Rework GstD3D11Memory API
Now resource view getter methods will provide strong reference
to each resource, so caller should release returned resources.
Another change is that caller MUST map GstD3D11Memory
via gst_d3d11_memory_map() method prior to getting resource view,
and any attempt to get resource view objects for non-mapped GstD3D11Memory
will be rejected by us.
Note that this change is prework for resource sharing among
different devices. Direct3D Resource sharing requires opening a new
Direct3D11 resource from existing resource handle and therefore
any resource views belong to one device is not usable for the other devices.
```
```
d3d11: Disallow GstD3D11Memory map for direct texture access via gst_memory_map()
... instead, user should use newly added gst_d3d11_memory_map() method.
gst_memory_map() method with GST_MAP_D3D11 approach is not suitable
for shared texture use case, since texture sharing requires more
context such as ID3D11Device handle to be shared.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2153d3d11: Move conversion objects to gst-libs2022-06-27T19:48:02ZSeungha Yangseungha@centricular.comd3d11: Move conversion objects to gst-libs... so that conversion methods can be used by non-d3d11 plugin scope.
Note that this API is still gst-plugins-bad scope, not for application.... so that conversion methods can be used by non-d3d11 plugin scope.
Note that this API is still gst-plugins-bad scope, not for application.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2053d3d11h264dec,d3d11h265dec: Add support for non-zero cropping window offset2022-06-27T19:45:40ZSeungha Yangseungha@centricular.comd3d11h264dec,d3d11h265dec: Add support for non-zero cropping window offset```
Decoder should be able to convey expected display area
information which is signalled via SPS.
To support non-zero cropping window offset (i.e., conf_win_left_offset
and/or conf_win_top_offset is not zero), we need to attach
GstVide...```
Decoder should be able to convey expected display area
information which is signalled via SPS.
To support non-zero cropping window offset (i.e., conf_win_left_offset
and/or conf_win_top_offset is not zero), we need to attach
GstVideoCropMeta if it's supported by downstream.
Or, only display area needs to be outputted if downstream doesn't
support GstVideoCropMeta.
Implementation-wise, in case that downstream is d3d11 element
and also supports GstVideoCropMeta
(currently none of d3d11 elements support it), d3d11 decoder will output
buffers without copying but GstVideoCropMeta will be attached instead.
Otherwise, decoded texture will be copied into downstream
buffer even if downstream is d3d11 element.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1265WIP: d3d11h264dec: Add support for DXVA_Slice_H264_Long2022-04-17T20:11:20ZSeungha Yangseungha@centricular.comWIP: d3d11h264dec: Add support for DXVA_Slice_H264_LongDXVA_Slice_H264_Long is rarely used for modern hardware
but it's worth to support this configuration for legacy devices.
depends on https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1238DXVA_Slice_H264_Long is rarely used for modern hardware
but it's worth to support this configuration for legacy devices.
depends on https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1238https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2030WIP: d3d11, mfvideoenc: Skip documentation for non-default devices2022-02-15T20:24:09ZSeungha Yangseungha@centricular.comWIP: d3d11, mfvideoenc: Skip documentation for non-default devicesDisable documentation for non-default devices by using new doc API.
Depends on https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/763Disable documentation for non-default devices by using new doc API.
Depends on https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/763https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2494wasapi2deviceprovider,mfdeviceprovider: Add support for device update2021-09-28T09:51:46ZSeungha Yangseungha@centricular.comwasapi2deviceprovider,mfdeviceprovider: Add support for device update```
mfdeviceprovider: Add support for device update
Similar to the wasapi2 plugin, GstWinRT library will be used for UWP,
and adding new GstWin32DeviceWatcher object implementation for
Win32 desktop application.
```
```...```
mfdeviceprovider: Add support for device update
Similar to the wasapi2 plugin, GstWinRT library will be used for UWP,
and adding new GstWin32DeviceWatcher object implementation for
Win32 desktop application.
```
```
wasapi2deviceprovider: Add support for device update
... by using newly implemented GstWinRT library
```
```
libs: Introduce GstWinRT library
Adding a helper library for various WinRT specific implementations.
Currently this library supports only DeviceWatcher abstraction object
which can be used for dynamic device add/remove detection.
See also
https://docs.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher?view=winrt-20348
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2536d3d11videosink: Add support for crop meta2021-09-27T12:35:50ZSeungha Yangseungha@centricular.comd3d11videosink: Add support for crop meta... when upstream element is d3d11.
Note that, if upstream element is not d3d11, crop meta is almost
pointless since d3d11videosink will upload video frame to GPU memory
in any case.... when upstream element is d3d11.
Note that, if upstream element is not d3d11, crop meta is almost
pointless since d3d11videosink will upload video frame to GPU memory
in any case.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1504dxgiscreencapsrc: Report latency of capture element2021-09-24T16:13:36ZSeungha Yangseungha@centricular.comdxgiscreencapsrc: Report latency of capture elementCopying a DXGI texture to system memory might introduce not ignorable
amount of latency depending on desktop resolution or so.Copying a DXGI texture to system memory might introduce not ignorable
amount of latency depending on desktop resolution or so.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1950wasapi: COM library is uninitialized automatically on thread exit.2021-09-24T14:11:41ZJacek Tomaszewskiwasapi: COM library is uninitialized automatically on thread exit.CoInitializeEx() and corresponding CoUninitialize() must be called from the same thread. Common mechanism for that using GPrivate was implemented in gstwasapiutil.c.
Fixes #1482 - CuUninitialize() was called from wrong thread disabling ...CoInitializeEx() and corresponding CoUninitialize() must be called from the same thread. Common mechanism for that using GPrivate was implemented in gstwasapiutil.c.
Fixes #1482 - CuUninitialize() was called from wrong thread disabling all COM functions in GUI.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1482https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2100d3d11h264dec: Allow zero-copy decoding via property even if fixed-size DPB te...2021-03-23T06:12:11ZSeungha Yangseungha@centricular.comd3d11h264dec: Allow zero-copy decoding via property even if fixed-size DPB texture pool is usedFor fixed-size DPB texture pool, we disabled zero-copy decoding
because of stability concern. For instance, in case that downstream
doesn't release zero-copied GstBuffer, it would result in deadlock
around decoder since DPB texture pool ...For fixed-size DPB texture pool, we disabled zero-copy decoding
because of stability concern. For instance, in case that downstream
doesn't release zero-copied GstBuffer, it would result in deadlock
around decoder since DPB texture pool cannot allocate additional texture
during playback once it's allocated.
This commit will allow zero-copy decoding via property even if fixed-size
pool is in use. In this case, user should set sufficiently
large DPB pool size via extra-output-views property so that
decoder can keep decoding by using pre-allocated extra DPB textures.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1471webrtc: Use Win32 API directly for resolving host in case of UWP2020-11-23T15:48:23ZSeungha Yangseungha@centricular.comwebrtc: Use Win32 API directly for resolving host in case of UWPGThreadedResolver contains some Windows APIs (belong to windns.h)
which are not allowed for UWP.
For the resolving purpose (i.e., getaddrinfo variants), however,
UWP application is allwed to use the WIN32 api.
cc: @nirbheek @ystreetGThreadedResolver contains some Windows APIs (belong to windns.h)
which are not allowed for UWP.
For the resolving purpose (i.e., getaddrinfo variants), however,
UWP application is allwed to use the WIN32 api.
cc: @nirbheek @ystreet1.17.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/625sctp: Fix crash on free() when using the MSVC binaries2019-08-20T10:23:14ZNirbheek Chauhannirbheek.chauhan@gmail.comsctp: Fix crash on free() when using the MSVC binariesOn Windows, if libusrsctp and gstreamer are built with different
C runtimes (CRT), we cannot free memory allocated inside libusrsctp
with the `free()` function from gstreamer's CRT.
`usrsctp_freedumpbuffer()` simply calls `free()`, but ...On Windows, if libusrsctp and gstreamer are built with different
C runtimes (CRT), we cannot free memory allocated inside libusrsctp
with the `free()` function from gstreamer's CRT.
`usrsctp_freedumpbuffer()` simply calls `free()`, but because of the
way DLLs work on Windows, it will always call the free function from
the correct CRT.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/172wasapi: Fix msvc link error "LNK2005: PKEY_AudioEndpoint_FormFactor already d...2019-08-12T03:55:21ZChangjiang Yangwasapi: Fix msvc link error "LNK2005: PKEY_AudioEndpoint_FormFactor already defined"When Ninja builds with msvc x64, there is link error "LNK2005: PKEY_AudioEndpoint_FormFactor already defined". Link with "/FORCE:MULTIPLE" option to fix the build.When Ninja builds with msvc x64, there is link error "LNK2005: PKEY_AudioEndpoint_FormFactor already defined". Link with "/FORCE:MULTIPLE" option to fix the build.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/213meson.build: Fix mingw format specifiers2019-02-22T11:30:29ZNacho Garciameson.build: Fix mingw format specifiersOn Windows, format specifiers like "%llu"
will issue a warning for 64bit integers
on ancient MINGW compilers.
To mitigate this problem, define
__USE_MINGW_ANSI_STDIO =1 can be used
to modify stdio.h behaviourOn Windows, format specifiers like "%llu"
will issue a warning for 64bit integers
on ancient MINGW compilers.
To mitigate this problem, define
__USE_MINGW_ANSI_STDIO =1 can be used
to modify stdio.h behaviour