Add a new wasapi implementation mainly to support UWP application.
Basically the core logic of this plugin is almost identical to
existing wasapi plugin, but main target is Windows 10 (+ UWP).
Since this plugin uses WinRT APIs, this plugin most likely might not
work Windows 8 or lower.
Compared with existing wasapi plugin, additional features of this plugin are
* Fully compatible with both Windows 10 desktop and UWP application
* Supports automatic stream routing (auto fallback when device was removed)
* Support device level mute/volume control
But some features of existing wasapi plugin are not implemented
in this plugin yet
* Exclusive streaming mode is not supported
* Loopback feature is not implemented
* Cross-compile is not possible with current mingw toolchain
(meaning that MSVC and Windows 10 SDK are required to build this plugin)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1264>
d3d11videosink has an advantage over d3dvideosink, such as
* Zero-copy playback with d3d11 decoders
* HDR rendering with 10-bit format/swapchain support
* UWP support
* Any system memory alignment/padding can be supported
* User can select target GPU device
And old d3dvideosink's functionality (e.g., navigation event, overlaycomposition)
can be covered by d3d11videosink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1311>
all msdk output surfaces come from out_alloc_resp, so the buffer count is not resizable.
we need set min_buffers, max_buffers to same size.
steps to reproduce
1. ffmpeg -f lavfi -i testsrc=duration=10:size=320x240:rate=30:decimals=3 -pix_fmt yuv420p -c:v libx265 ~/bits/hevc/test.265
2. GST_GL_PLATFORM=egl gst-launch-1.0 -v filesrc location=~/bits/hevc/test.265 ! h265parse ! msdkh265dec ! msdkvpp ! queue ! glimagesink
you will see error like this:
ERROR default gstmsdkvideomemory.c:77:gst_msdk_video_allocator_get_surface: failed to get surface available
ERROR msdkbufferpool gstmsdkbufferpool.c:270:gst_msdk_buffer_pool_alloc_buffer:<msdkbufferpool2> failed to create new MSDK memory
ERROR msdkvpp gstmsdkvpp.c:297:create_output_buffer:<msdkvpp0> failed to create output video buffer
ERROR msdkdec gstmsdkdec.c:699:gst_msdkdec_finish_task:<msdkh265dec0> Failed to finish frame
ERROR msdkdec gstmsdkdec.c:1085:gst_msdkdec_handle_frame:<msdkh265dec0> Failed to finish a task
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1278>
Add MediaFoundation AAC encoder element.
Before Windows 10, mono and stereo channels were supported audio channels
configuration by AAC encoder MFT. However, on Windows 10,
5.1 channels support was introduced.
To expose correct range of support format by this element
whatever the OS version is, this element will enumerate
all the supported format by the AAC encoder MFT
and then will configure sink/src templates while plugin init.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1280>
If parent and child windows are running on different thread,
there is always a chance to cause deadlock as DefWindowProc() call
from child window thread might be blocked until the message
is handled by parent's window procedure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1299>
GObject::dispose method can be called multiple times. As win32 d3d11window
has an internal thread and because GObject::dispose method could be called from the
thread, it might cause problems such as trying to join self-thread
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1299>
New video capture implementation using WinRT Media APIs for UWP app.
Due to the strict permission policy of UWP, device enumeration and
open should be done via new WinRT APIs and to get permission from users,
it will invoke permission dialog on UI.
Strictly saying, this implementation is not a part of MediaFoundation
but structurally it's very similar to MediaFoundation API.
So we can avoid some code duplication by adding this implementation
into MediaFoundation plugin.
This implementation requires UniversalApiContract version >= 6.0
which is part of Windows 10 version 1803 (Redstone 4)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1241>
There was a missing break for the 4:4:4 case which would break the sizeimage
calculation. We don't currently have hardware that supports 4:4:4, so this
code wasn't tested. This was detected by Coverity.
CID 1463592 1463591
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1283>
The Cedrus driver would otherwise choose 1KB buffer, which is too small.
This follows what some drivers do, which is simply to use the size a
packed raw image would have. Specifications do not really guaranty any minimum
compression ratio.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1268>
This adds support for slice based decoder like the Allwinner/Cedrus driver. In
order to keep things efficient, we hold the sink buffer until we reach the end
of the picture. Note that as we don't know which one is last, we lazy queue the
slices. This effectively introduces one slice latency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1268>
GstD3D11ColorConverter implementation is able to rescale video as well.
By doing colorspace conversion and rescale at once, we can save
one cycle of shader pipeline which will can save GPU resource.
Since this element can support color space conversion and rescale,
it's renamed as d3d11convert
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1275>
This commit does the following things to fix compilation on FreeBSD:
1. Add required typedefs to linux/types-compat.h.
2. Remove unnecessary include linux/ioctl.h and replace linux/types.h
with linux/types-compat.h. Both files do not exist on FreeBSD.
3. Check the header including makedev macro. FreeBSD does not have
sys/sysmacros.h, and including it unconditionally causes error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1259>
else gst_video_meta_validate_alignment will report error like
"videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (384) is different from the one computed from the alignment (320)"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1224>
In section 9.3.4 a), segment_feature_mode have 0 for absolute and 1 for delta,
while in 19.2, it says the opposite. But the reference code, which usually
rules over the text state that 1 means absolute:
if (hdr->update_data)
{
hdr->abs = bool_get_bit(bool);
And uses it with that meaning to decide weither to override the existing value
or just add the detla. This fixes multiple decoding issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1245>
