In case the wasapi buffer levels got low in shared mode we would still wait until
more buffer is available until writing something in it, which means we could never
catch up and recover.
Instead only wait for a new buffer in case the existing one is full and always write
what we can. Also don't loop until all data is written since the base class can handle
that for us and under normal circumstances this doesn't happen anyway.
This only works in shared mode, as in exclusive mode we have to exactly
fill the buffer and always have to wait first.
This fixes noisy (buffer underrun) playback with the wasapisink under load.
https://bugzilla.gnome.org/show_bug.cgi?id=796354
The calculation for the frame count in the non-aligned case resulted in
a one too low buffer frame count.
This resulted in:
1) exclusive mode not working as the frame count has to match
exactly there.
2) Buffer underruns in shared mode as the current write() code doesn't
handle catching up to low buffer levels (fixed in the next commit)
To fix just use the wasapi API to get the buffer size which will always
be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=796354
S_FALSE is a valid return value which does not indicate an error.
For example IAudioClient_Stop() returns S_FALSE when it is already stopped.
Use the FAILED macro instead which just checks if an error occured or not.
This fixes spurious warnings when using the wasapisink element.
https://bugzilla.gnome.org/show_bug.cgi?id=796280
This is a new warning introduced by gcc 8
We already check just before that we have enough space, just do a regular
memcpy with the full string size.
camswclient.c:87:3: error: ‘strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
'cuDeviceComputeCapability' was deprecated as of CUDA 5.0
gstnvenc.c: In function ‘gst_nvenc_create_cuda_context’:
gstnvenc.c:290:9: error: ‘cuDeviceComputeCapability’ is deprecated [-Werror=deprecated-declarations]
&& cuDeviceComputeCapability (&maj, &min, cdev) == CUDA_SUCCESS) {
^
https://bugzilla.gnome.org/show_bug.cgi?id=796203
The new property "output-order" can be set to either "display" order
which is the default where frames will be outputting in display order,
or "decoded-order" which will be outputting the frames in decoded order.
The "decoded order" output is generally useful for debugging. But there
are few
customers who use it for low-latency streaming. For eg if the customer
already knows that the stream doesn't have b-frames (which means no
algorithm requires for display order calculation), then they can use
"decoded-order"
output to skip some of the DPB logic to avoid the frame accumulation at
start-up.
The root cause of the above issue is a bit of unclarity in h264 spec +
lazy implementation of many H264 encoders; This is well handled in
gstreamer-vaapi using "low-latency" property:
https://bugzilla.gnome.org/show_bug.cgi?id=762509https://bugzilla.gnome.org/show_bug.cgi?id=795783
For packetized input, inform the msdk that the buffer has
a complete frame or complementary field pairs. For decoding,
this means that the decoder can proceed with this buffer without
waiting for the start of the next frame, which effectively reduces
decoding latency.
https://bugzilla.gnome.org/show_bug.cgi?id=795783
Currently we use an async depth of 4 as default (based on
recommendations
in msdk apps), which indicates how many asynchronous operations an
application performs
before the application explicitly synchronizes the result. As a result,
we
queue four frames in decoder which might not be good approach for
live streaming.
This patch reset the async-depth to 1 as default so that we do sync for
each frame we decode without queuing. Customer can play with already
exposed "async-depth" property for other use cases
https://bugzilla.gnome.org/show_bug.cgi?id=795783
So far msdk produced dmabuf fds are non-mappable.
If user wants to download the content of underlined surfaces,
dmabufcapsfeature negotiated pipeline will fail. So if the input surface
is dmabuf and downstream doesn't have support for dmabuf capsfeatures,
we do the vpp (no passthrough) and produce the mappable videomemory
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=794946
prpose_allocation:
-- always instantiate a pool for for upstream
-- use async_depth + 1 as min buffer count
decide_allocation:
-- always create a new bufferpool for source pad.
Each of the msdk element has to create it's own mfxsurfacepool
which is an msdk contraint. For eg: Each Msdk component (vpp, dec and
enc)
will invoke the external Frame allocator for video-memory usage
So sharing the pool between gst-msdk elements might not be a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=793705
If the "output-cc" property is set to TRUE and there is CC present
in the VBI Ancillary Data, they will be extracted and set on the
outgoing buffer as GstVideoCaptionMeta.
Only CDP packets are supported.
https://bugzilla.gnome.org/show_bug.cgi?id=773863
This adds entry for new DRM driver from xilinx
called "xlnx" which supports atomic modesetting.
We have kept entry for older DRM driver "xilinx_drm"
for backward compatility with a note describing
deprecation.
Signed-off-by: Devarsh Thakkar <devarsht@xilinx.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795228
The clock seems to have a lot of drift (or we're using it incorrectly)
which causes buffers to be late on the sink and get dropped.
Disable till someone can investigate whether our usage of the API is
incorrect (it looked correct to me) or if something is wrong.
Since cuda-tools 9.0, nvcuvid.h is replaced by dynlink_nvcuvid.h.
This patch changes nvdec to use run-time dynamic linking if
cuda-tools version >= 9.
nvenc does not require any change since its necessary headers are
still available.
https://bugzilla.gnome.org/show_bug.cgi?id=791724
Using the default value (InterleavedDec == MFX_SCANTYPE_UNKNOWN)
causing issues with non-interleaved sample decode. Ideally the usage
of MFXVideoDECODE_DecodeHeader should fix these type of issue, but
it seems to be not. But hardcoding the InterleaveDec to
MFX_SCANTYPE_NONINTERLEAVED
is fixing the problem and fortunately msdk seems to be taking care of
Interleaved samples
too .So let's hardcode it for now.
https://bugzilla.gnome.org/show_bug.cgi?id=793787
We can just return the template caps till the device is opened when
going from READY -> PAUSED. This fixes a CRITICAL when calling
ELEMENT_ERROR before the ringbuffer is allocated.
Also fixes a couple of leaks in error conditions.
https://bugzilla.gnome.org/show_bug.cgi?id=794611
Now, when you set loopback=true on wasapisrc, the `device` property
should refer to a sink (render) device for loopback recording.
If the `device` property is not set, the default sink device is used.
This patch includes:
1\ Implements MsdkDmaBufAllocator and allocation of msdk dmabuf memroy.
2\ Each msdk dmabuf memory include its own msdk surface kept by GQuark.
3\ Adds new option GST_BUFFER_POOL_OPTION_MSDK_USE_DMABUF
https://bugzilla.gnome.org/show_bug.cgi?id=793707
There needs to be generalized for the parameter from
GstVideoMsdkVideoMemory to GstMemory.
Thus we can call these functions if using DMABuf memory.
https://bugzilla.gnome.org/show_bug.cgi?id=793707
For example, if framerate 0/1 is provided from upstream, the driver
fails to configure and complain about it.
We can let it go and make the driver assuming framerate itself.
https://bugzilla.gnome.org/show_bug.cgi?id=789752
There is no log of gst_decklink_com_thread () which initializes COM.
The initialization part is not valid with #ifdef MSC_VER.
Windows binaries are built with gcc.
As with other codes, it was avoidable by setting it to G_OS_WIN32
instead of MSC_VER.
https://bugzilla.gnome.org/show_bug.cgi?id=794652
There was not handling the end of encoding sequence in encoder.
This patch does drain any remaining internal streams while decoder
already does this.
Document says:
"To mark the end of the encoding sequence, call this function with a
NULL surface
pointer. Repeat the call to drain any remaining internally cached
bitstreams—one
frame at a time—until MFX_ERR_MORE_DATA is returned."
https://bugzilla.gnome.org/show_bug.cgi?id=793236
Sometimes parent context is released before its children get released.
In this case MFXClose of parent session fails.
To make sure that child sessions are closed before closing a parent
session,
Parent context needs to manage child sessions and close them first when
it's released.
https://bugzilla.gnome.org/show_bug.cgi?id=793412
Currently a gst buffer has one mfxFrameSurface when it's allocated and
can't be changed.
This is based on that the life of gst buffer and mfxFrameSurface would
be same.
But it's not true. Sometimes even if a gst buffer of a frame is finished
on downstream,
mfxFramesurface coupled with the gst buffer is still locked, which means
it's still being used in the driver.
So this patch does this.
Every time a gst buffer is acquired from the pool, it confirms if the
surface coupled with the buffer is unlocked.
If not, replace it with new unlocked one.
In this way, user(decoder or encoder) doesn't need to manage gst buffers
including locked surface.
To do that, this patch includes the following:
1. GstMsdkContext
- Manages MSDK surfaces available, used, locked respectively as the
following:
1\ surfaces_avail : surfaces which are free and unused anywhere
2\ surfaces_used : surfaces coupled with a gst buffer and being used
now.
3\ surfaces_locked : surfaces still locked even after the gst buffer
is released.
- Provide an api to get MSDK surface available.
- Provide an api to release MSDK surface.
2. GstMsdkVideoMemory
- Gets a surface available when it's allocated.
- Provide an api to get an available surface with new unlocked one.
- Provide an api to release surface in the msdk video memory.
3. GstMsdkBufferPool
- In acquire_buffer, every time a gst buffer is acquired, get new
available surface from the list.
- In release_buffer, it confirms if the buffer's surface is unlocked or
not.
- If unlocked, it is put to the available list.
- If still locked, it is put to the locked list.
This also fixes bug #793525.
https://bugzilla.gnome.org/show_bug.cgi?id=793413https://bugzilla.gnome.org/show_bug.cgi?id=793525
Directsoundsrc/sink have multiple issues, most of which cannot be
fixed at all because the API is deprecated and is implemented as a
compatibility wrapper around WASAPI since Vista.
Users and developers should now use the wasapisrc/sink elements, and
future development efforts should go towards that.
The low-latency property is *always* safe to enable, so applications
that do realtime communication should set it, and the elements will
automatically configure WASAPI to use the lowest possible device
period, and the audioringbuffer in audiobasesink will also be
configured accordingly.
Applications can also use exclusive mode during capture and playback
for the lowest possible latency if they know that the device will not
be used by any other application.
In this mode, the latency-time and buffer-time properties will be
completely ignored.
