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]

video/x-vp9 is required in the src pad, however the output includes a
IVF header, which makes the pipeline below doesn't work

  gst-launch-1.0 videotestsrc ! msdkvp9enc ! msdkvp9dec ! fakesink

Since mfx 1.26, the VP9 encoder supports bitstream without IVF header,
so in this patch, the mfx version is checked and msdkvp9enc is enabled
only if mfx 1.26+ is available

User is seeing corrupted display when running `videotestsrc !
video/x-raw,format=NV12,width=xxx,height=xxx ! msdkh265enc ! msdkh265dec
! glimagesink` with changed frame size, e.g. from 1920x1080 to 1920x240

The root cause is a same dmabuf fd is used for frames with
different size, which causes some unexpected result. This patch requires
cached response is used for frames with same size only for DMABuf, so a
dmabuf fd can't be used for frames with different size any more.

This reverts commit 24ecb3f8.

Nirbheek Chauhan authored Jan 17, 2020 and Haihao Xiang committed Jan 21, 2020

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 gstreamer/gst-plugins-bad#946

Nirbheek Chauhan authored Jan 17, 2020 and Haihao Xiang committed Jan 21, 2020

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.

Nirbheek Chauhan authored Jan 17, 2020 and Haihao Xiang committed Jan 21, 2020

`gst_object_replace()` is not supposed to be used for unreffing and
NULLing objects.

We weren't printing the return value.

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`.

Just a nitpick. Also, force the compiler to use our stub header
instead of searching for it in the include paths.

Sebastian Dröge authored Jan 17, 2020 and GStreamer Marge Bot committed Jan 19, 2020

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.

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

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 gstreamer/gst-plugins-bad#758

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

Previously we would've returned NEW, which is usually more wrong.

Sebastian Dröge authored Jan 09, 2020 and GStreamer Marge Bot committed Jan 19, 2020

They're now mapping exactly to what
  https://www.w3.org/TR/webrtc/#rtcpeerconnectionstate-enum
actually specifies.

Related to gstreamer/gst-plugins-bad#758

Sebastian Dröge authored Jan 09, 2020 and GStreamer Marge Bot committed Jan 19, 2020

They're now mapping exactly to what
  https://www.w3.org/TR/webrtc/#dom-rtciceconnectionstate
actually specifies.

Related to gstreamer/gst-plugins-bad#758

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

Fixes gstreamer/gst-plugins-bad#758

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

This allows the application to keep track of the underlying DTLS
connection state and act accordingly.

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

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.

Sebastian Dröge authored Jan 12, 2020 and GStreamer Marge Bot committed Jan 19, 2020

There's not point in using GClosure and going through all the
GValue/libffi infrastructure for each DTLS packet.

Sebastian Dröge authored Jan 09, 2020 and GStreamer Marge Bot committed Jan 19, 2020

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 gstreamer/gst-plugins-bad#1126

Sebastian Dröge authored Jan 09, 2020 and GStreamer Marge Bot committed Jan 19, 2020

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 gstreamer/gst-plugins-bad#1126

Jan Schmidt authored Dec 31, 2019 and GStreamer Marge Bot committed Jan 19, 2020

The meson build doesn't automatically set HAVE_CPU_* defines
like autotools did, so the yadif plugin was being built without
the MMX assembler support

Josep Torra authored Nov 06, 2019 and Haihao Xiang committed Jan 19, 2020

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 ! ...
```

Seungha Yang authored Nov 28, 2019 and GStreamer Marge Bot committed Jan 16, 2020

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.

Seungha Yang authored Nov 28, 2019 and GStreamer Marge Bot committed Jan 16, 2020

Update header to query minimum resolution of encoder and to control
the number of reference frame if it's supported

Copied and pasted from gstreamer-vaapi and did a few changes for gst-msdk.

Allow the base class to copy GstVideoRegionOfInterestMeta data to the
output buffer when calling gst_video_decoder_finish_frame

A reconfig is needed when ROI is changed, otherwise the ROI parameters won't
take effect

set_extra_params is added to allow sub class to add extra mfx parameters
for changed input frame or meta data

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.

Seungha Yang authored Jan 13, 2020 and GStreamer Marge Bot committed Jan 14, 2020

... and handle EOS and EOB nals.

Only the first CRA picture should be associated with NoRaslOutputFlag
as the comment in code.

`@videolibdir@` isn't used anymore.