player: Avoid trying to join the player thread from itself

https://bugzilla.gnome.org/show_bug.cgi?id=796731

webrtc: Explicitly initialise mutex and condition

Fixes random crashes when an allocated webrtcbin isn't
given fresh 0-filled memory in its allocation. It works
mostly because GMutex and GCond are automatically initialised
in that case.

webrtc: Move the transportsendbin pad block removal

Move freeing of the pad blocks back to before we call the
GstBin state change function, as there's something racy
going on on the build server otherwise, where the pads don't
unblock during downward state changes.

This is a bit of a stab in the dark, since I can't recreate
the build server failure locally.

aomenc: Handle 8 bit_depth images with AOM_IMG_FMT_HIGHBITDEPTH enabled

https://bugzilla.gnome.org/show_bug.cgi?id=791674

aomenc: Add support for 10/12bit decoding

https://bugzilla.gnome.org/show_bug.cgi?id=791674

ivfparse: Add the AV01 FOURCC for parsing AV1 IVFs

Adds AV01 FOURCC to the list of allowed media files, in order to allow
parsing the IVF Container holding AV1 content.
At a later point dynamic resolution change can be supported - therefore
the sequence header OBU and frame header OBU of AV1 file must be parsed,
which can be done in future with the help of gst-lib gstav1parse.

https://bugzilla.gnome.org/show_bug.cgi?id=796677

meson: Add fallback for openh264 dependency

webrtc: Clean up pad block allocs on dispose.

Release references in pad blocks and release the memory in the
dispose function too, in case the state change doesn't get
run (because calling the parent state change fails).

webrtc: Don't deadlock on block pads on shutdown

When changing state downward, we can't set pads
to inactive if they are blocked, it will deadlock
trying to acquire the streaming lock.

Just calling the parent state change function
will do the correct things to unblock probes and
set the pad inactive, so let it do that and
remove the probes after the parent state change
function has run

https://bugzilla.gnome.org/show_bug.cgi?id=796682

winks: Update for g_type_class_add_private() deprecation in recent GLib

Untested

msdk: Update for g_type_class_add_private() deprecation in recent GLib

Untested.

libs: Update for g_type_class_add_private() deprecation in recent GLib

videoaggregator: Update for g_type_class_add_private() deprecation in recent GLib

gl: Update for g_type_class_add_private() deprecation in recent GLib

vulkan: Update for g_type_class_add_private() deprecation in recent GLib

soundtouch: Update for g_type_class_add_private() deprecation in recent GLib

dtls: Update for g_type_class_add_private() deprecation in recent GLib

webrtc: Update for g_type_class_add_private() deprecation in recent GLib

uvch264src: get rid of unnecessary private struct

jpegformat: get rid of unnecessary private structs

ext/closedcaption/misc.h: Transform into UTF-8

decklink: Fix warning about HRESULT not being unsigned int

tsdemux: Don't set invalid seqnum on segment event

https://bugzilla.gnome.org/show_bug.cgi?id=796623

pitch: remove trailing whitespaces from previous commit

pitch: Flush only if there are unprocessed samples

Otherwise we end up trying to flush before
sample rate of SoundTouch is set

https://bugzilla.gnome.org/show_bug.cgi?id=796613

tests: Make sure to provide the KEY_UNIT flag always together with the SNAP flags in seeks

SNAP flags alone make no sense and nowadays cause warnings.

pitch: preserve seek event seqnums

This was wreaking havoc when used with a downstream audiomixer.

https://bugzilla.gnome.org/show_bug.cgi?id=796603

pitch: fix latency reporting

When max is GST_CLOCK_TIME_NONE in the query, it should not
be set in the query handler, this otherwise could lead to
impossible situations, where the minimum latency ended up
greater than the maximum.

https://bugzilla.gnome.org/show_bug.cgi?id=796603

pitch: Fix single input buffer followed by EOS

The flush function immediately returned when pitch->next_buffer_offset
was 0.

This is clearly wrong, as next_buffer_offset can be 0 when a single
input buffer has been received, and no output buffer has been produced
before receiving EOS.

Simply remove that condition.

https://bugzilla.gnome.org/show_bug.cgi?id=796603

videoaggregator: Fix string leak

gst_video_colorimetry_to_string() returns allocated memory which
must be freed.

https://bugzilla.gnome.org/show_bug.cgi?id=796596

androidmedia: Invert the transform matrix from the decoder

The transform from mediacodec applies to the texture coords, but
GStreamer affine meta applies to the video geometry, which is the
opposite - so invert it to get display correct for decoders
that require transforming

vulkaninstance: add missing precondition to _open()

tsdemux: Don't query duration if program isn't active

gst_webrtc_session_description_new: fix annotations

videoaggregator: log an ERROR if we're going to return a flow error

msdk: vpp: remove mfxExtVPPDoUse from vpp filters.

According to msdk spec, there are two ways to enable filters:
1: Filters can be enabled by adding a filter ID
to mfxExtVPPDoUse. In this case, default filter parameters are used
2: Add filter configuration structures directly to mfxVideoParam.

Using 1 with 2 is optional but legal. Unfortunately it won't work
with some specific use cases like Detail/EdgeEnhancement.
Let's stick with option2 which works fine for all VPP operations.

https://bugzilla.gnome.org/show_bug.cgi?id=796468

msdk: vpp: set passthrough from set_caps method for code clarity

Call passthrough setting method from set_caps so that
msdk initialize subroutine looks more clear.

mskd: vpp: error out gracefully instead of segfaulting if Init failed

Since we do the MSDK initializing in set_caps(), a FALSE
return may still cause the invokation of set_caps() again
and this will leads to buffer allocation and other mess-up.
So make sure the msdk initialized correctly before trying
to do any buffer allocation.

https://bugzilla.gnome.org/show_bug.cgi?id=796465

msdk: vpp: Add filters to VideoParm before doing the Query

Make sure all the enabled filter structures are added in the
mfxVideoParm before doing the VPPQuery so that msdk
can do the input param validation

https://bugzilla.gnome.org/show_bug.cgi?id=796465

examples: Don't install non-prefixed examples

examples: Build waylandsink example

mpegtsdemux: Fix SEGMENT seqnum propagation

* If the seek was handled upstream, use that SEGMENT seqnum
* Use the proper invalid default value

vdpau: Run gst-indent

msdk: vpp: fix the filter count in mfxExtVPPDoUse

Repostion the mfxExtVPPDoUse enabling code
so that it will get the filter algorithm count correctly.

webrtc: Fix wrong parent classes for DTLSTransport and ICETransport

Those are GObjects not GstBins

player: Fix duration-changed CRITICAL warning if duration did not actually change

Check if duration is changed before emitting duration-changed signal

https://bugzilla.gnome.org/show_bug.cgi?id=796491

dvb: Fix typo in comment termination

dvb: update my email address

dvb: camconditionalaccess: fix wrong license headers

Update the license blurb in camconditionalaccess.[hc] from GPL to LGPL.
The plugin is LGPL and the GPL header in those two files was just a
copy/paste mistake.

gitignore: Add h265parser test

codecparsers: mpeg2: don't mess the StartCode only packets

It is completely legal to have packets with zero sizes.
Zero-sized packet indicates header with only Start Code.
One eg: is user data packet. The patch allows having
GstMpegVideoPacket with zero sizes.

https://bugzilla.gnome.org/show_bug.cgi?id=796477

msdk: vpp: don't use NV12 as vpp default output for DMABuf usecase

Using NV12 layout in dmabuf mode giving mis-aligned
VPP output with the media-driver. Keep the NV12 support
(so that we can file the bug agianst msdk or mediadriver),
but lower the ordering so that BGRA picks as default.

NV12 issue can be reproduced with explicit capfilter:
vidoetestsrc ! msdkvpp ! video/x-raw\(memory:DMABuf\),format=NV12 ! glimagesink

msdk: enc: Add supprot for dmabuf-import

MediaSDK requires all the input buffers to be
pre-allocated during init phase and this won't work with
current design of GStreamer or gst-msdk. But this can be
done in future once we have a solution for:
https://bugzilla.gnome.org/show_bug.cgi?id=795747

There is a workaround possible as per
https://github.com/Intel-Media-SDK/MediaSDK/issues/155#issuecomment-381790504
by faking the mem-id during MFXInit.
This patch enabling it in gst-msdk by replacing the MemID of mfxSurface
with dmabuf-backed vasurface dynamically.

Important: v4l2 ! msdkenc won't work without a copy because
of the GMMLib (https://github.com/intel/gmmlib) memory restrictions.

https://bugzilla.gnome.org/show_bug.cgi?id=794817

msdk: vpp: Add supprot for dmabuf-import

MediaSDK requires all the input and output buffers to be
pre-allocated during init phase and this won't work with
current design of GStreamer or gst-msdk. But this can be
done with https://bugzilla.gnome.org/show_bug.cgi?id=795747

There is a workaround possible as per
https://github.com/Intel-Media-SDK/MediaSDK/issues/155#issuecomment-381790504
by faking the mem-id during MFXInit.
This patch do this in gst-msdk by replacing the MemID of mfxSurface
with dmabuf-backed vasurface dynamically.

Important: v4l2 ! msdkvpp won't work without a copy because
of the GMMLib (https://github.com/intel/gmmlib) memory restrictions.

https://bugzilla.gnome.org/show_bug.cgi?id=794817

msdk: Add method to replace internal VASurface of mfxFrameSurface

Added a utility method to replace the MemID (interanl VASurfaceID)
associated with the mfxFrameSurface. This is usefull for dmabuf-import
where we need to replace the memID dynamically

https://bugzilla.gnome.org/show_bug.cgi?id=794817

msdk: Add method to export dmabuf to VASurface

Exporting DRM_PRIME fd to VASurface requires direct
invocation of VA api VACreateSurface with
VASurfaceAttribExternalBufferDescriptor and other
necessary surface attributes.

https://bugzilla.gnome.org/show_bug.cgi?id=794817

webrtcbin: copy sticky events on our ghostpads

This lets users call gst_pad_get_current_caps on newly-added
pads to easily determine what to plug them into.

We cannot copy sticky events unconditionally in core,
see #719437

https://bugzilla.gnome.org/show_bug.cgi?id=796387

adaptivedemux: Set connection-speed value as current download rate if set

If connection-speed property is in use, this value should be used as the
current download rate since subclasses might read it to figure out
which playlist variant they will use.

https://bugzilla.gnome.org/show_bug.cgi?id=784592

closedcaption: Fix compilation without debugging

ceaccoverlay: New CEA-708 Closed Caption decoder and overlayer

This new element allows decoding and overlaying CEA-708 Closed Caption
streams over video.

* Supports CDP and cc_data closedcaption/x-cea-708 streams
* Uses pango to render CC stream
* Support GstVideoOverlayComposition meta if downstream supports is

Tested on various test files.

Remains to be fixed/improved:
* Switch to GstByteReader (for code safety)
* Switch to GString (instead of manual pango string construction)
* Move pango/rendering code outside of main 708 decoder file (so
  that actual CC parser/decoder can be (re)used in other scenarios).

Initial patches and improvements by:
* CableLabs RUIH-RI Team <ruihri@cablelabs.com>
* Steve Maynard <steve@secondstryke.com>
* cjun.wang" <cjun.wang@samsung.com>

https://bugzilla.gnome.org/show_bug.cgi?id=704881

closedcaption: fix meson build

closedcaption: Add new "line 21 VBI" CC decoder

Allows detecting and extracting CEA608 closed caption present on
the VBI of analog NTSC SD signals.

closedcaption: zvbi: Add gst-debug category to zvbi code

And adapt their logging system to go through it

closedcaption: zvbi: Disable unused legacy bit slicer

The code only uses the new 'optimized' bit slicer

closedcaption: zvbi: Enforce strict line21 CC detection

zvbi switched to a lot more flexible CC detection in VBI.

The problem is that it returns a *lot* of non-VBI lines as containing
CC which isn't the case.

closedcaption: zvbi: Comment out bogus redefinition

All this code should be converted to glib eventually, but for now
just comment out a function which isn't even used

closedcaption: zvbi: Remove dead code

* RGB8 is never used
* some inline functions were never used

closedcaption: Include zvbi raw vbi decoder code

Current code from zapping/zvbi as of 2018-03-14. Files copied
are all LGPL v2+.

Changes from original zvbi code:
* Switch to gst-debug logging system
* Use glib for endianness detection
* Fix compilation warnings

closedcaption: add meson build files

ext: New ccextractor element

Allows extracting GstVideoCaptionMeta from a stream and outputs
it to a standalone stream.

Part of a new 'ext' closedcaption plugin, since more features are
going to be added, which will depend on external dependencies such
as pango.

webrtcbin: rtpstorage takes a 64-bit integer for "size-time" property

https://bugzilla.gnome.org/show_bug.cgi?id=796429

directfb: don't error out for warnings in system headers

On debian system headers trigger compiler warnings like these,
don't error out on them:
/usr/include/directfb/direct/os/linux/glibc/waitqueue.h:95:1: note: previous definition of ‘direct_waitqueue_signal’ was here

gitignore: Add new webrtc example

wasapisink: recover from low buffer levels in shared mode

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

wasapisink: fix a rounding error when calculating the buffer frame count

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

wasapisink: fix missing unlock in case IAudioClient_Start fails

https://bugzilla.gnome.org/show_bug.cgi?id=796354

wasapi: use FAILED to detect errors

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

wasapi: Don't pass CoTaskMemFree to g_clear_pointer

CoTaskMemFree has a different calling convention than GDestroyNotify
and things crash at least with MinGW.

https://bugzilla.gnome.org/show_bug.cgi?id=796280

meson: fix libnice fallback options

meson: add 'nls' option to disable translations

And enable by default. Was implicitly disabled because
ENABLE_NLS was not defined.

webrtc: add some default options for libnice fallback

The tests are not very reliable, so disable for now.

mpegts: Add GIR generation array anotations

For function parameters that are known to be arrays.

https://bugzilla.gnome.org/show_bug.cgi?id=796221

dvb: Fix string copy wiht strlen() argument

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=]

libs: g-ir-scanner: do not hardcode libtool path

https://bugzilla.gnome.org/show_bug.cgi?id=726571

nvdec/nvenc: Bump up supported CUDA Toolkit version

Add CUDA 9.2 to configure.ac

https://bugzilla.gnome.org/show_bug.cgi?id=796202

nvenc: Fix build warning error

'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

videoaggregator: Remove custom get_next_time implementation

GstAggregator now has the same thing in the simple implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=795486

msdk: Add conditional build for vp9 decoder

https://bugzilla.gnome.org/show_bug.cgi?id=796119

msdk: dec: Add VP9 decoder

https://bugzilla.gnome.org/show_bug.cgi?id=796119

msdk: allow building against open sourced msdk

Building against mfx_dispatcher is used to search for
headers in PREFIX/include/mfx/ only (commit: 62f04e801bd7e247102ac67df889bee33ab74ff7),
but it is just PREFIX/include with open source msdk version.

https://bugzilla.gnome.org/show_bug.cgi?id=796118

dashdemux: Fix sync of updated manifest from previous one

_get_next_fragment_timestamp() returns relative timestamp to period start.
But gst_mpd_client_stream_seek() uses absolute MPD timeline.

https://bugzilla.gnome.org/show_bug.cgi?id=781183

adaptivedemux: Support period change in live playlist

Regardless of LIVE or VOD, "a manifest has next period but
currently EOSed" state is meaning that it's time to advance period.

Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.

https://bugzilla.gnome.org/show_bug.cgi?id=781183

srtp: Add "roc" caps field to the gst-launch example

The currrent example was broken since 1.8.3 it seems.

https://bugzilla.gnome.org/show_bug.cgi?id=786304

decklink: Fix crash with closed-captions signal and 10-bit input

Only free the parser if there is one. If the format hadn't changed but
had always been 10-bit, there might genuinely be no parser.

https://bugzilla.gnome.org/show_bug.cgi?id=796030

decklinkvideosrc: Don't check for closed captions when there's no signal

Otherwise the gst_decklink_video_format_from_type() call spams the logs
with one "Unknown pixel format 0x0" line per frame.

opencv: Fix memcpy within C++

Explicitly cast to void* because GCC 8 is (rightfully) upset that this is
"writing to an object of type ‘...’ with no trivial copy-assignment".

Caused by the new "class-memaccess" warning

webrtcbin: implement support for FEC and RTX

https://bugzilla.gnome.org/show_bug.cgi?id=795044

msdk:dec: Add new propery to dump frames in decoded order

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=762509

https://bugzilla.gnome.org/show_bug.cgi?id=795783

msdk: dec: inform msdk if the buffer contains a complete frame

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

msdk: dec: reset async depth to one

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