gl: x11: fix compiler warning

glcontext: add public swap_buffers function

That simply calls the implementation

examples: gl: remove ancient bitrotten .vcproj files

adaptivedemux: fix debug message printf format

Match gsize to G_GSIZE_FORMAT in the debug message.

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

win32: update .def file for API removal

audiointerleave: Take object lock while modifying channel count

aggregator: Remove unused GST_FLOW_NOT_HANDLED

aggregator: add simple support for caps handling

Modelled off the videoaggregator caps handling as that seems the most
mature aggregtor-using implementation that has caps handling there is.

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

aggregator: Reset upstream latency on first buffer

In the case an aggregator is created and pads are requested but only
linked later, we end up never updating the upstream latency.
This was because latency queries on pads that are not linked succeed,
so we never did a new query once a live source has been linked, so the
thread was never started.

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

videoaggregator: delay using new caps from a sink pad until the next buffer in the queue is taken

When caps changes while streaming, the new caps was getting processed
immediately in videoaggregator, but the next buffer in the queue that
corresponds to this new caps was not necessarily being used immediately,
which resulted sometimes in using an old buffer with new caps. Of course
there used to be a separate buffer_vinfo for mapping the buffer with its
own caps, but in compositor the GstVideoConverter was still using wrong
info and resulted in invalid reads and corrupt output.

This approach here is more safe. We delay using the new caps
until we actually select the next buffer in the queue for use.
This way we also eliminate the need for buffer_vinfo, since the
pad->info is always in sync with the format of the selected buffer.

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

aggregator: Always handle sync'ed events on output thread

Having all synchronized events always be handled on the output
thread should make synchronization easier.

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

aggregator: Delay clipping to output thread

This is required because the synchronized events like caps or segments
may only be processed on the output thread.

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

aggregator: Make pad eos as soon as all buffers are processed, dont way for events

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

aggregator: Only count buffers when declaring queue full

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

tests: Test caps using query

Sending an event can accepted event if the caps were rejected
because the event could be queued and processed later.

Also send a drain query in the caps test to make sure that the
event has been processed.

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

aggregator: Simplify clip function

The return value was ignored anyway

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

aggregator: Only declare first buffer on actual buffer

The function needs to be unlocked if any data is received, but only
end the first buffer processing on an actual buffer, synchronized events
don't matter on the first buffer processing.

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

aggregator: Set initial position on first buffer

Set the initial position on the first buffer, otherwise the queue
will grow without limits before the output thread is started.

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

aggregator: Reset the pad's first buffer flag with the rest

There is not reason to have separate code to reset this one.

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

aggregator: Reset pad on init

Factor out the pad reset code from the flushing and use it on init as well

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

aggregator: Fix indentation

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

glcontext: keep a ref to the active thread

With the macOS/iOS implementations, the active thread can change
multiple times over the life of a pipeline which would expose a race in
the thread tracking.

Fix by taking a ref on the active thread while the context is active.

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

meson: add options to set package name and origin

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

examples: fix macOS 9.12 deprecation warnings

Add #defines to allow older versions of macOS to use the new constant names.

cocoa: fix a recently introduced typo

Fixes gstgldisplay_cocoa.m:175:26: error: use of undeclared identifier 'singletone'.

cocoa: fix macOS 10.12 deprecation warnings

Add #defines to allow older versions of macOS to use the new constant names.

dashdemux: Use correct (sub) fragment start when clipping chunk size

If we didn't download anything yet, we shouldn't use fragment.start but
the start position of the current sidx entry.

dashdemux: Make sure to pass the next buffer after a seek with DISCONT flag

When we manually seek for skipping ahead in keyunit-only trickmode, we
have to enforce that ourselves as adaptivedemux does not know about the
seeks.

dashdemux: Ensure that we never ever download over the current SIDX entry

Even if downloading more than needed to try to get the moof and first
keyframe both together.

dashdemux: Take SIDX entry timestamp/duration into account for keyunit-only mode

And not the whole segment's timestamp/duration

dashdemux: Reset parsing state correctly in various places

dashdemux: Reset previous target_time when seeking

dashdemux: Smooth out skip distances in keyframe-only trick modes

This ensures smoother playback. It looks weird if we first do a big
jump, then play a couple of consecutive frames, just to again skip ahead
quite a bit because we ran late again.

dashdemux: Take configure max bitrate/framerate into account for keyframe skipping

And by default only produce up to 10 fps.

dashdemux: Try harder to not run into a loop over the same fragment over and over

While still making sure to not jump ahead one fragment further than
needed.

dashdemux: Add some debug output to the target time selection

dashdemux: Use the current clock running time in addition to the QoS earliest time

dashdemux: Download keyframes from the current position if we're far enough ahead

Far enough here means more than 500ms or 4 times the average keyframe
download time. There is no need to jump ahead by one average keyframe
download time in this case.

This makes playback smooth if the network is fast enough.

dashdemux: Fix sync sample selection based on target time in reverse playback mode

dashdemux: Snap-seek for skipping ahead and use actual keyframe distance in the current fragment if applicable

dashdemux: Don't adjust for fragment duration twice when seeking ahead in KEYUNITS mode

dashdemux: Add current fragment duration in reverse playback mode to the position

We play from the end of the fragment to the beginning, not from the
beginning backwards.

dashdemux: Never take more than the current fragment duration for estimations inside the fragment

Taking the average might give us from results.

dashdemux: Don't increase current position if we just downloaded the moof in KEYUNIT mode

dashdemux: Improve key-unit trick mode downloading

When dealing with key-unit trick mode downloads, the goal is to
provide the best "Quality of Experience". This is achieved by:
1) maximizing the number of frames displayed per second
2) avoiding "stalling" as much as possible (i.e. not downloading and
  decoding frames fast enough)

This implementation achives this by:
1) Knowing very precisely the current keyframe being download (i.e
  more accurate than at the fragment level which might contain more
  than one keyfram). This is the new "actual_position" variable
  introduced by this commit
2) Knowing the position of downstream (provided by QoS and stored
  in the adaptivedemuxstream qos_earliest_time variable)
3) Knowing how long it takes to request and fully download a keyframe
  (the average_download_time variable)

Taking those 3 variables into account, whenever a keyframe has been
pushed downstream we calculate a "target time" (target_time variable)
which is the ideal next keyframe time to request so that:
1) It will be requested/downloaded/demuxed/decoded in time to be
  displayed without being too late
2) It will not be too far ahead that it would cause too few frames
  per second to be displayed.

How far ahead we will request is inversily proportional to how close
the actual position (actual_position) is from the downstream
position (qos_earliest_time). The more is buffered between the source
and the sink, the "closer" the target time will be, and therefore
the more frames per seconds will be displayed (up to the limit
of keyframes_per_second * absolute_rate).

dashdemux: Store average download time

This will be used to bound the download rate when working in
keyframe-only trick mode

adaptivedemux: Add various comments to the code

adaptivedemux: Store QoS time

Allows subclasses to know where downstream is and make decisions
based upon that

dashdemux: Collect keyunit distance and size statistics

dashdemux: Disable bitrate switching in key-unit trick mode

This creates too much havoc for now

dashdemux: Use new adaptivedemux trickmode macro

Reduces the lines of code, and makes it a bit more readable

adaptivedemux: Add a macro to know if we are in trickmode-keyunit

Reduces the amount of lines of code in subclasses

uvch264src: Apply timestamps to outgoing aux buffers

When extracting an aux buffer from an MJPG carrier, at
*least* put the original timestamp on it, even if we
fail to apply any other timestamp (which we always do
at the moment, because the timestamp calculating code
was never finished). Apply a DTS using the camera
supplied delay value as well, assuming that there's
no re-ordering going on (there isn't in the C920,
which is really the only extant camera doing this
stuff) and a warning if that turns out not to be true.

qt: Use GST_GL_HAVE_PLATFORM_CGL instead of GST_GL_HAVE_PLATFORM_COCOA

The latter is not used/available anymore since years. Also fix a typo
in the include path for the Cocoa GL display header.

motioncells: delay motionmaskcoords until caps arrive

motionmaskcoords is not applied on start because the information
about resolution isn't available until caps arrive.

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

amcvideodec: Unref downstream caps after usage

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

Fix up package name and origin in some plugins

stereo: fix typo in plugin description

h265parse: Fix calculation of codec_data buffer size

glformat: Add missing GST_GL_RGB565 in some switch statement

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

cocoa: Install gstgldisplay_cocoa.h

It's needed by e.g. qmlglsink.

gst: Clear floating flag in constructor of all GstObject subclasses that are not owned by any parent

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

decklink: Sink the clock reference in the constructor

This is now needed as GstClock does not do that internally anymore,
because that broke bindings.

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

qml: Add EGL platform support for x11 backend

Add support for EGL platform when x11 is available. This can work
e.g. on imx6 platform.

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

Remove plugin specific static build option

Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.

dashdemux: Initialize sidx_position to GST_CLOCK_TIME_NONE

If a manifest has non-zero presentation time offset
(i.e., earliest presentation time specified by sidx box is not zero),
the initial sidx position shouldn't be zero. Since we cannot define
exact sidx position until parsing sidx box, set the value to unknown.

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

adaptivedemux: Handle stop_type:SET, stop:NONE

Seek values of type GST_SEEK_TYPE_SET with values of GST_CLOCK_TIME_NONE
are perfectly valid (we essentially don't modify the existing position)

decklinkvideosink: Copy min(gstreamer_stride, decklink_stride) per line

Instead of just bpp * width, which might be more than we can copy.

glshader: Make reference counting of attach() consistent

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

h265parse: fix caps leak in renegotiation

h264parse: fix caps leak in renegotiation

jpeg2000parse: fix negotiation with j2c and jpc both allowed upstream

If upstream supports both, but downstream supports only jpc, j2c
would have been selected as the first in the caps.

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

hlssink2: New HLS sink element based on splitmuxsink

This embeds the muxer inside the sink and accepts elementary streams
while the old HLS sink required the muxer outside. Apart from that the
interface is the same as before.
Currently only mpegtsmux is supported, but support for other muxers is
just a matter of adding a property.

The advantage of the new sink is that it reduces complexity a lot and
properly handles pre-encoded streams with appropriately spaced
keyframes.

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

decklinkvideo/audiosrc: Add GstReferenceTimestampMeta with the stream time to each buffer

This is basically a frame counter provided by the driver and it's
advancing at the speed of the HDMI/SDI input. Having this available on
each buffer allows to know what constant-framerate-based timestamp each
frame is corresponding to and can be used e.g. to write out files
accordingly without having the local pipeline clock timestamps used.

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

decklinkaudiosrc: Consistently pass stream_time and stream_duration to audio/video src

It's the same value now, pass it consistently.

directsoundsrc: Use a GstClockID to wait instead of Sleep()

The main advantage is that our sleeps can be interrupted in case of
an src_reset(). Earlier, we would need to wait for a read to complete
before we could do a reset, which could take a long time.

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

audiobuffersplit: Allow changing the output-buffer-duration at any time

Previously this was only allowed before the CAPS event arrived.

opencv/meson: Allow 3.2.0

This was already added and tested in autoconf.

build/gl/meson: check for GLES3/gl3ext.h existence

791e7522ebcb75beb31fcace271dee1342d3505d for meson

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

build: Check for GLES3/gl3ext.h existence

Some OpenGL drivers do not ship this but use GLES2/gl2ext.h instead.
This is also in line with Khronos's recommendations

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

msdk: Declare libmfx.a as a C++ static library

This lets meson know that the overall plugin needs built with C++
linking.

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

decklink: Always use the video stream time for audio too

The audio packet times can be completely unrelated to the video stream
time, depending on the card. While this looks like a bug in the driver,
just always using the video stream time (which is correct) works as a
workaround for now.

opencv/meson: Ensure variable opencv_found is set

If the required version is not satisfied, we need to make sure this
variable is set, otherwise build will fail.

Bump and update for meson 0.40.1

This patch bumps the required meson to 0.40.1 as gstreamer core just
did, and cleanup some code to use a feature from 0.37 that allow
specifying version range when checking dependency.

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

opusparse: do not drop preskip and gain from OpusHead header

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

qmlgl: Make the plugin name match the pugin file name

gme: Make the plugin name match the plugin library name

neon: Make the plugin name match the plugin library

glmemory: Only use glDrawBuffer if available

Otherwise fall back to glDrawBuffers. Also check if glReadBuffer exists
before using it.

glDrawBuffer does not exist for GLES, only glDrawBuffers does.

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

adaptivedemux: Handle more live seeking use-cases

This commit fixes the following assumptions with live seeking:
1) start was always valid and of type GST_SEEK_TYPE_SET
2) direction was always forward
3) stop should be offsetted when handling non-accurate seeks before
   the range start position.

In order to handle more live seeking use-cases (including reverse playback),
only do non-accurate start/stop value clamping for GST_SEEK_TYPE_SET values.

Also add a bit more debugging lines for issues

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

adaptivedemux: Implement GST_SEEK_TYPE_END usage for live

When dealing with live streams, we can't rely on GstSegment calculation
since it uses the segment duration to calculate the absolute values.

But since we are dealing with live *and* we know the ranges, we can
compute the absolute seeking values using the range stop (i.e. "now")
as the END position.

Allows seeking back to "live" by using start_type:GST_SEEK_TYPE_END
and start:0

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

meson: Ignore msvc warnings in C++ as well

We were only ignoring the listed msvc warnings for C language
files and not C++. This was working by the coincidence that we did
not have any instances of these warnings in C++ files. Lately the
build of decklink has been fixed on windows, and it has an
instance of one of these warnings in a C++ file.

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

directsoundsrc: Use latency-time and buffer-time settings

Earlier, the plugin was ignoring those settings and blindly setting
buffer-time to 2 seconds and latency-time to 200ms, which forced all
pipelines to have a minimum latency of 200ms + sink latency.

The values of segsize and segtotal were also not derived correctly.
Now we obey these values, and you can get close to the previous
behaviour by setting buffer-time and latency-time manually. Note that
they are set in microseconds.

As a consequence, when we haven't received enough data from the
device, we now sleep for a time proportional to the data remaining.
However, Directsound is a deprecated API so it maintains its own
software ringbuffer which updates at arbitrary intervals. Hence we
might have to wait a full segsize to get the last 10% of data. To
avoid tight loops, we clamp our sleep floor at 10ms.

In my testing, this keeps the wakeups not-too-high (proportional to
the latency-time set on the source). Further improvements should be
made by fixing the WASAPI audio source plugin instead of this.
Directsound is deprecated and as the comments explain, it is
impossible to get low latency, decent quality, or good performance
from it.

Based on a patch by Sebastian Dröge <sebastian@centricular.com>

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

glvideomixer: fix whole example launch line actually

glvideomixer: remove extraneous \ from example launch line in docs

adaptivedemux: Allow live seeking range to go back to "now"

The allowed live seek ranges returned by subclasses are "inclusive", that is
to say that the "range_stop" value they return is the highest acceptable position
one can seek to (i.e. "now").

Allow seeking to exactly that value

Revert "decklink: Fix debug logging warnings on Windows"

This reverts commit 845832263ba6b9e135b23e9a29c9d109cb2ee9c4.

The commit broke cross-mingw CI:
https://ci.gstreamer.net/job/GStreamer-master/8659/console

It seems that cross-mingw on Autotools and native-mingw on Meson
disagree about the size of HRESULT. Revert for now till I can
investigate the Meson side of things some more.

decklink: Fix linking on MinGW

MinGW does not provide comsupp.lib, so there's no implementation of
_com_util::ConvertBSTRToString. Use a fallback implementation that
uses wcstombs() instead.

On MinGW we also truncate the name to 100 chars which should be fine.

decklink: Fix building on Windows

BSTR is already a pointer to a string

decklink: Fix debug logging warnings on Windows

HRESULT is unsigned long int, not unsigned int