Don't specify the resolution of backbuffer. Then dxgi will let us know the
actual client area. When upstream resolution is chagned, updating the size
of backbuffer without the consideration for client size would cause mismatch
between them.
Setting the CUVID_PKT_DISCONTINUITY implies clearing any past information
about the stream in the decoder. The GStreamer discont flag is used for
discontinuity caused by a seek, for first buffer and if a buffer was
dropped. In the first two cases, the parsers and demuxers should ensure we
start from a synchronization point, so it's unlikely that delta will be
matched against the wrong state.
For packet lost, the discontinuity flag will prevent the decoder from doing
any concealment, with a result that ca be much worst visually, or freeze the
playback until an IDR is met. It's better to let the decoder handle that for
us.
Removing this flag, also workaround a but in NVidia parser that makes it
ignore our ENDOFFRAME flag and increase the latency by one frame.
This sets the CUVID_PKT_ENDOFPICTURE flag in order to inform the decoder that
we have a complete picture. This should remove one frame latency otherwise
introduce by NVidia parser.
If we have no DTS but a PTS then this means both are the same, and we
should update the last_ts with the PTS. Only if both are unknown then we
don't know the current position and should not update it at all.
Previously we would always update the last_ts to GST_CLOCK_TIME_NONE if
the DTS is unknown, which caused the position to jump around and to
cause spurious gap events to be sent.
This patch fixed compiler warning below:
[1/4] Compiling C object 'sys/msdk/dc44ea0@@gstmsdk@sha/gstmsdkvpp.c.o'.
../../gst-plugins-bad/sys/msdk/gstmsdkvpp.c: In function
‘gst_msdkvpp_context_prepare’:
../../gst-plugins-bad/sys/msdk/gstmsdkvpp.c:214:7: warning: suggest
parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘!’ to ‘~’
[-Wparentheses]
We need the streams' pt maps updated before requesting pads
on rtpbin, because this is what will trigger the requesting
of FEC encoders, and our handler for this request looks for
the payload types in the relevant stream's pt map.
Fixes#1187
Instead of doing it on each packet and doing it based on the distance to
the previous SCR instead of based on the DTS.
Previously we would send gap events for audio all the time if the SCR
distance was 400ms because the threshold for audio is 300ms and by only
ever updating the position when the SCR updates we would always be 100ms
above the threshold and send needless gap events.
This fixes audio glitches on various files caused by gap events.
Our context is non-persistent, and we propagate it throughout the
pipeline. This means that if we try to reuse any gstmsdk element by
removing it from the pipeline and then re-adding it, we'll clone the
mfxSession and create a new gstmsdk context as a child of the old one
inside `gst_msdk_context_new_with_parent()`.
Normally this only allocates a few KB inside the driver, but on
Windows it seems to allocate tens of MBs which leads to linearly
increasing memory usage for each PLAYING->NULL->PLAYING state cycle
for the process. The contexts will only be freed when the pipeline
itself goes to `NULL`, which would defeat the purpose of dynamic
pipelines.
Essentially, we need to optimize the case in which the element is
removed from the pipeline and re-added and the same context is re-set
on it. To detect that case, we set the context on `old_context`, and
compare it to the new one when preparing the context. If they're the
same, we don't need to do anything.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/946
Split it out into a separate function with early exits to make the
flow clearer, and document what the function is doing clearly.
No functional changes.
We weren't using the correct calling convention when calling CUDA and
CUVID APIs. `CUDAAPI` is `__stdcall` on Windows. This was working fine
on x64 because `__stdcall` is ignored and there's no special calling
convention. However, on x86, we need to use `__stdcall`.
Otherwise we would start sending data to the DTLS connection before, and
the DTLS elements consider this an error.
Also RFC 8261 mentions:
o A DTLS connection MUST be established before an SCTP association can
be set up.
For us it can happen that the DTLS transports are still in the process
of connecting while the ICE transport is already completed. This
situation is not specified in the spec but conceptually that means it is
still in the process of connecting.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/758
Previously we simply logged errors but never reported them to elements
or even to the user. Fatal errors are now properly reported.
Additionally proper connection closing is implemented based on EOS:
- dtlsenc: EOS will cause close_notify to be sent to the peer and only
if the peer also sent back close_notify we will forward the
EOS event.
- dtlsdec: EOS will be forwarded normally, this only means that the
unterlying transport was closed. On receiving a DTLS packet
containing close_notify, return EOS and send EOS downstream.
We don't have any mid before parsing the SDP, which happens after we
handled the SDP answer and that usually happens long after ICE candidate
gathering is finished.
Without this all transceivers are considered inactive and as such ICE
gathering is for active transceiver was considered complete from the
very beginning.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1126
We don't support stopping RTP receivers currently so let's not consider
them all stopped all the time. This fixes some of the ICE/DTLS state
change handling and specifically fixes the ICE gathering state.
Previously the ICE gathering state was immediately going from NEW to
COMPLETE because it considered all transceivers stopped and as such all
activate transceivers were finished gathering ICE candidates.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1126
Before this change decoder used the oldest frame in the list to pair it
with the decoded surface. This only works when there's a perfect stream
like HEADERS,SYNCPOINT,DELTA...
When playing RTSP streams we can get imperfect streams like HEADERS,
DELTA,SYNCPOINT,DELTA... In this case decoder drops the frames
between HEADERS and SYNCPOINT which leads into using wrong PTS on
the output frames.
With this change we inject the input PTS into the bitstream and use it
to align the internal frame list with the actually decoded position.
Fixes playback with:
```
gst-launch-1.0 rtspsrc location=... latency=0 drop-on-latency=1 ! ...
```
Hard-coded 16x16 resolution is likely to differ from the device's support
in most cases. If we can use NV_ENC_CAPS_WIDTH_MIN and NV_ENC_CAPS_HEIGHT_MIN,
update pad template with returned value.
need_reconfig is added to allow sub class requires a reconfig when
the input frame or the MetaData (e.g. GstVideoRegionOfInterestMeta)
attached to the input frame is changed.
`pipe()` isn't used since 15927b6511,
and `socketpair()` from `#include <sys/socket.h>` is used only in the
examples. In practice, you can use probably also use anything that
allows you to create fd pairs, such as named pipes or anonymous pipes.
We use the cross-platform GstPollFD API in the plugin.
Use consistent memory layout between dxva and other shader use case.
For example, use DXGI_FORMAT_NV12 texture format instead of
two textures with DXGI_FORMAT_R8_UNORM and DXGI_FORMAT_R8G8_UNORM.
This reverts commit ddd13fc7c0
Dynamic usage can reduce the number of copy per frame but make
things complicated and the benefit seems to not significant.
Also since we don't provide _map() method for the dynamic usage,
application cannot read buffers which make "last-sample" property
unusable in case of d3d11videosink.
