Extensions and layers can be enabled before calling
gst_vulkan_instance_open() but after calling
gst_vulkan_instance_fill_info().
Use the list of available extensions to better choose a default display
implementation to use based on the available Vulkan extensions for surface
output.
Defaults are still the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1341>
Until now, bound check would simply trace the values and the range. This
enhances the trace by also tracing the name of the variable that was to be set
or read. This is not magically perfect in all cases, but greatly speed the
debugging work. Here's an example before and after this change:
Before: gst_h264_parser_parse_slice_hdr: value not in allowed range. value: 819183, range -87-77
After: gst_h264_parser_parse_slice_hdr: value for 'slice->slice_qp_delta' not in allowed range. value: 819183, range -87-77
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1356>
Unfortunately it means those tune enums don't show up in
the docs then, but if that's how it's gotta be..
(Problem at hand is that on Tim's machine x265enc gets an
tune=animation and on the CI machine this doesn't show up.)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1354>
Now that autotools has been removed generate a meson project template in
gst-project-maker.
There are some differences with the autotools project
1. gstreamer-controller-1.0 is not added to the default dependencies.
2. The '-Wall' option is not set explicitly, meson can handle that.
3. The flags in GST_PLUGIN_LDFLAGS have not been ported to meson as
they are not necessary anymore.
The generated project requires meson 0.53.0 for the 'fs' module. It's up
to the user to remove that part in case compatibility with older
versions of meson is desired.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/184>
It was introduced for later use of its enhanced feature over IMFSourceReader
such as taking photo with video preview, audio/video capturing at
the same time, etc. But currently it's not our use case, and it would
be maintenance burden.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1342>
Add an element that converts AYUV video frames to a DVB
subpicture stream.
It's fairly simple for now. Later it would be good to support
input via a stream that contains only GstVideoOverlayComposition
meta.
The element searches each input video frame for the largest
sub-region containing non-transparent pixels and encodes that
as a single DVB subpicture region. It can also do palette
reduction of the input frames using code taken from
libimagequant.
There are various FIXME for potential improvements for now, but
it works.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1227>
This element uses the Desktop Duplication API to capture the desktop screen at high speed.
It supports Windows 8 or later.
It has the following features compared to other elements:
* Runs faster.
* It works in High DPI environment.
* Draws an accurate mouse cursor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/863>
previous code releases GstBuffer too earlier. so we will see
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:<msdkbufferpool0> failed to create new MSDK memory
We need to hold GstBuffer reference for msdk if the surfaced locked by msdk.
step to reproduce.
1. ffmpeg -f lavfi -i testsrc=duration=10:size=320x240:rate=30 -pix_fmt yuv420p -c:v libx265 test.265
2. GST_GL_PLATFORM=egl gst-launch-1.0 -v filesrc location=test.265 ! h265parse ! msdkh265dec ! queue ! glimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1277>
If the src_peer_caps are EMPTY (e.g. negotiation failed somewhere), the
assertion inside gst_video_info_from_caps would fail and the whole
pipeline would crash. Check for gst_caps_is_empty before
gst_video_info_from_caps and gracefully fail if it's empty.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1333>
This sequence of event/data flow might happen
1) Initially we have one pending output event
1-1) Then, process the pending output data
2) No pending input event, then we should wait new pending input event
2-1) Wakeup by new pending event (but it's pending output event)
In above case, MFT will not report new pending input event
if pending output is not processed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1325>
