* Fix meson build script for Windows. Since the Vulkan dependency
object was declared by us in case of Windows, the dependency object
shouldn't be used for finding header
* Fix build error by including Windows specific header
gstvkdisplay.c(563): error C2065: 'VK_KHR_WIN32_SURFACE_EXTENSION_NAME': undeclared identifier
The convert-error signal is emitted whenever we get a GstFlowReturn
other than GST_FLOW_OK. The handler can then decide what to convert that
into - for instance, return the same GstFlowReturn to not convert it.
The default handler will act according to the ignore-error,
ignore-notlinked, ignore-notnegotiated and convert-to properties. If a
handler is connected, these properties are ignored.
In file included from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstbin.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gst.h:35,
from ../gst/rtp/gstrtpsink.h:23,
from ../gst/rtp/gstrtpsink.c:49:
In function ‘gst_rtp_sink_start’,
inlined from ‘gst_rtp_sink_change_state’ at ../gst/rtp/gstrtpsink.c:509:11:
../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstelement.h:422:18: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
422 | gchar *__txt = _gst_element_error_printf text; \
../gst/rtp/gstrtpsink.c:476:3: note: in expansion of macro ‘GST_ELEMENT_ERROR’
476 | GST_ELEMENT_ERROR (self, RESOURCE, NOT_FOUND,
| ^~~~~~~~~~~~~~~~~
../gst/rtp/gstrtpsink.c: In function ‘gst_rtp_sink_change_state’:
../gst/rtp/gstrtpsink.c:477:37: note: format string is defined here
477 | ("Could not resolve hostname '%s'", remote_addr),
| ^~
In file included from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstbin.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gst.h:35,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/rtp/gstrtpdefs.h:27,
from ../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/rtp/rtp.h:25,
from ../gst/rist/gstristsink.c:72:
In function ‘gst_rist_sink_setup_rtcp_socket’,
inlined from ‘gst_rist_sink_start’ at ../gst/rist/gstristsink.c:658:10,
inlined from ‘gst_rist_sink_change_state’ at ../gst/rist/gstristsink.c:801:13:
../../../../dist/linux_x86_64/include/gstreamer-1.0/gst/gstelement.h:422:18: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
422 | gchar *__txt = _gst_element_error_printf text; \
../gst/rist/gstristsink.c:595:3: note: in expansion of macro ‘GST_ELEMENT_ERROR’
595 | GST_ELEMENT_ERROR (sink, RESOURCE, NOT_FOUND,
| ^~~~~~~~~~~~~~~~~
../gst/rist/gstristsink.c: In function ‘gst_rist_sink_change_state’:
../gst/rist/gstristsink.c:596:37: note: format string is defined here
596 | ("Could not resolve hostname '%s'", remote_addr),
| ^~
Both MSDK and this plugin use mfxFrameAllocResponse for video and DMABuf
memory, it is possible that some GST buffers are still in use when calling
gst_msdk_frame_free, so add a reference count in the wrapper of
mfxFrameAllocResponse (GstMsdkAllocResponse) to make sure the underlying
mfx resources are still available if the corresponding buffer pool is in
use.
In addtion, currently all allocators for input or output share the same
mfxFrameAllocResponse pointer in an element, so it is possible that
the content of mfxFrameAllocResponse is updated for a new caps then all
GST buffers allocated from an old allocator will use this new content of
mfxFrameAllocResponse, which will result in unexpected behavior. In this
fix, we save the the content of mfxFrameAllocResponse in the corresponding
tructure to avoid such issue
Sample pipeline:
gst-launch-1.0 filesrc location=vp9_multi_resolutions.ivf ! ivfparse ! msdkvp9dec !
msdkvpp ! video/x-raw\(memory:DMABuf\),format=NV12 ! glimagesink
Otherwise it is possible that different wrappers share the same
mfxFrameAllocResponse pointer, so instead of caching the pointer, we may
cache the content of mfxFrameAllocResponse
For a skipped frame in VC1, MSDK returns the mfx surface of the reference
frame, so we have to make sure the corresponding surface for the
reference frame is not freed. In this fix, we postpone surface free because
we don't know whether a surface is referenced
Before this fix, the error is like as below:
New clock: GstSystemClock
0:00:00.181793130 23098 0x55f8a9d622d0 ERROR msdkdec
gstmsdkdec.c:622:gst_msdkdec_finish_task:<msdkvc1dec0> Couldn't find the
cached MSDK surface
Sample pipeline:
gst-launch-1.0 filesrc location=input_has_skipped_frame.wmv ! asfdemux !
vc1parse ! msdkvc1dec ! glimagesink
If the surface is not in use, we may release it even if GST_FLOW_OK is going
to be returned, which may avoid the issue of failing to get surface
available
This fixes the regression caused by commit c05acf4
GstAllocationParams::align is set to 31 in msdkdec/msdken/msdkvpp, hence
the stride align should be greater than or equal to 31, otherwise it
will result in issue
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/861
(msdk: "GStreamer-CRITICAL: gst_buffer_resize_range failed" SPAM),
In addition, the stride should match the pitch alignment in the media driver,
otherwise it will result in some issues when a buffer is shared between
different elements, e.g. the NV12 issue mentioned in commit 3f2314a, which
can be reproduced by `gst-launch-1.0 vidoetestsrc ! msdkvpp !
video/x-raw\(memory:DMABuf\),format=NV12 ! glimagesink`
Fixed https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/861
1. The iOS create_surface implementation needs to call out to the main
thread to create the window (UIKit requirement)
2. get_surface() can be called and will attempt to create the VkSurface
from an invalid view/layer.
Also pass the layer for MoltenVK so we don't get pesky 'UIView function
not called on main thread' warnings.
For some hevc 10bit 4K encoding cases, the encoding process may be
slow, and MediaSDK surface can't be released in time before one other
available surface is needed. So add an extra surface for hevc encoding
to avoid this issue.
Internal sources seem to be rtp streams we are sending whereas
non-internal sources are the rtp streams we are receiving. Redo the
statistics with that in mind.
If the last flow was not GST_FLOW_OK, the encoding thread is not running
and there is nothing to pop from GAsyncQueue (this causes deadlock).
To prevent deadlock, just return the handle_frame without further encoding
process if the last flow was not GST_FLOW_OK. Note that the last flow
will be cleared per FLUSH_STOP and STREAM_START event.
The hard-coded upper bound 32 (or 48 depending on resolution) might waste
GPU memory and high resolution encoding causes OUT-OF-MEMORY allocation error
quite easily. This commit calculates the number of required pre-allocated
device memory based on encoding options and it can reduce the amount of device memory
used by nvenc.
NVDEC driver always uses input timestamp without adjustment
even if bframe encoding was enabled.
So DTS can be larger than PTS when bframe was enabled.
To ensure PTS >= DTS, we should adjust the timestamp manually
based on the PTS difference between the first
encoded frame and the second one. That's also the maximum PTS/DTS
difference.
To support rc-lookahead and bframe encoding, nvenc needs one more
staging queue, because NvEncEncodePicture can return NV_ENC_ERR_NEED_MORE_INPUT
but which was not considered so far.
As documented by NVENC programming guide, pending buffers should wait
other inputs until NvEncEncodePicture returns success.
New encoding flow is
- Submit raw picture buffer to encoder with NvEncEncodePicture
- The submitted input/output buffer pair will be queued to pending_queue
- If NvEncEncodePicture returned success, then move all pair in pending_queue
to final stage
- Otherwise, wait more input raw pictures.
Another change is dropping NV_ENC_LOCK_INPUT_BUFFER usage.
So now nvenc always uses CUDA memory input buffer. As a result,
both opengl and system memory handling are unified.
* The number of iteration is always one so the iteration is useless
and that makes code complicated.
* Also defining named structure can code mroe readable.
* g_free is null safe
New rate-control modes are introduced (if device can support)
* cbr-ld-hr: CBR low-delay high quality
* cbr-hq: CBR high quality
* vbr-hq: VBR high quality
Also, various configurable rate-control related properties are added.
