wasapi: Guard IAudioClient2 structs and enums

These are already defined in the audioclient.h provided by the latest
MinGW headers, and the existing #ifndef were obviously wrong.

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

docs: add wasapi elements

meson: fix build when msdk is not found

tests: add msdkh264enc element unit test

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

msdk: Fix the misspelled file name in meson build

wasapi: ship audioclient3 header in tarballs

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

msdk: enc: fix missing some frames to be encoded

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

msdk: dec: fix leaks when flushing

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

msdk: manage child sessions on parent GstMsdkContext

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

msdk: dec: remove code to manage buffers with locked surface

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

msdk: manage MSDK surfaces seperately

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=793413
https://bugzilla.gnome.org/show_bug.cgi?id=793525

configure.ac: enable largefile support if possible

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

tests: player: disable broken test_play_media_info test

Until someone can be bothered to debug + fix it.

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

h265parser: allow partial matching on range extension profile

Best to return a valid profiles rather than no profile if bitstream uses
a not standard profile.

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

h265parse: add support for 'Format range extensions profiles'

Those profiles have been introduced in version 2 of the HEVC spec
(A.3.5).

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

h265parser: parse extra profile fields

Those fields have been introduced in version 2 and later to define new
profiles like the format range extensions profiles (A.3.5).

NOTE: This patch breaks the parser ABI, rebuild needed.

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

h265parser: decouple GstH265Profile and GstH265ProfileIDC

We used to have the same enum to represent H265 profiles and idc values.
Those are no longer the same with extension profiles defined from
version 2 of the spec.
Split those enums so the semantic of each is clearer and we'll be able
to add extension profiles to GstH265Profile.

Also add gst_h265_profile_tier_level_get_profile() to retrieve the
GstH265Profile from the GstH265ProfileTierLevel. It will be used to
implement the detection of extension profiles.

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

Release 1.13.90

Update docs

iqa: Fix build with latest aggregator API changes

Revert "h265parse: early set src caps when input not byte-stream"

This reverts commit 93d29e80300f566b7a8e7d86beecb578fe03821c.

Revert "h264parse: early set src caps when input is avc"

This reverts commit 5ac886d85aab4b919f84fb80e2d1ef36dc8e647d.

meson: enable more warnings

Remove schroedinger plugin

No upstream (website disappeared), no maintainer, and
pretty much a fringe format anyway.

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

Port to latest GstAggregator segment API

The aggregator segment is now exposed on the src pad

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

wasapi: Increase rank to prefer over directsoundsrc

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.

mxfmux: instantiate adapter at the correct place

docs: add new audiolatency element to docs and update docs for git

audiolatency: Fix string format specifier and use microseconds everywhere

Should fix warnings or build errors on 32-bit platforms and on Windows.

Also clarify in logging that all timestamps are in microseconds.

audiolatency: Fix cerbero build failure

Average latency is a 64-bit integer.

https://ci.gstreamer.net/job/GStreamer-master/9962/

x265enc: Add format example for option-string

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

audiolatency: New plugin for measuring audio latency

Measures the audio latency between the source pad and the sink pad by
outputting period ticks on the source pad and measuring how long they
take to arrive on the sink pad.

Very useful for quantifying latency improvements in audio pipelines.
This plugin was particularly useful during development of the
low-latency features of the wasapi plugin.

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

ttml: Add support for IMSC 1.0.1 fillLineGap attribute

Strictly speaking, the TTML spec requires that text backgrounds extend
only to the font height of the related text, rather than to the vertical
distance between lines. The result of this is that there will typically
be vertical gaps between line backgrounds through which moving video can
be seen. Since this was unnacceptable to some content providers, v1.0.1
of the IMSC spec (which profiles TTML) adds a new attribute,
itts:fillLineGap[1], that allows content authors to specify that clients
should extend text backgrounds such that there are no gaps between
lines. This attribute is also going to be included in the next release
of EBU-TT-D.

This patch adds support for fillLineGap to ttmlparse and ttmlrender.

[1] https://www.w3.org/TR/ttml-imsc1.0.1/#itts-fillLineGap

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

docs: plugins: add some more elements

Many will still be missing corresponding doc
sections in the source code though.

wasapi: Clarify usage of low-latency property, add myself as author

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.

wasapi: Add a property for trying the AudioClient3 API

The AudioClient3 API is only available on Windows 10, and we will
automatically detect when it is available and use it.

However, using it for capturing audio with low latency and without
glitches seems to require setting the realtime priority of the entire
pipeline to "critical", which we cannot do from inside the element.

Hence, we can only enable that by default for wasapisink since
apps should be able to safely set the low-latency property to TRUE if
they need low-latency capture or playback.

wasapi: Set realtime thread priority at runtime

Use LoadLibrary() to set the thread characteristics at runtime so it
works automagically regardless of where or how the plugin was built.

wasapi: Use IAudioClient3 interface when available

This allows us to request ultra-low-latency device periods even in
shared mode. However, this requires good drivers and Windows 10, so
we only enable this when we detect that we are running on Windows 10
at runtime.

You can forcibly disable this feature on Windows 10 by setting
GST_WASAPI_DISABLE_AUDIOCLIENT3=1 in the environment.

wasapi: __uuidof is simply not available in C

Fix comment, and don't try to use it at all.

wasapi: Set a default category for util functions

Without this, they all go to the default category where they can be
missed

wasapi: Use a macro for HRESULT failure paths

Saves a lot of boilerplate across all files.

checksumsink: remove src pad template from sink element

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

msdk: remove unused code

There's unused code remaining since MSDK bufferpool patches landed.

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

srt: Add support for streamheaders to sinks

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

srt: Refactor gst_srt_*_sink_send_buffer, extract send

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

srt: Add gst_srt_base_sink_stop

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

srt: Remove unused queued_buffers field

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

msdkenc: remove unnecessary memset

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

msdk: enc: Support force-key-unit events

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

h264parser: Expose framerate even if fixed_frame_rate flag isn't set

There is nothing in the spec that state that framerate is not valid in
that case. This aligns GStreamer with FFMPEG behaviour for similar
streams.

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

meson: simplify GST_DISABLE_GST_DEBUG check and don't use add_global_*

add_global_arguments() can't be used in subprojects. It's
entirely possible that -bad is a subproject but gstreamer
is picked up from an installed location, so we should
really use add_project_arguments() in both cases.

doc: Add section for fakevideosink

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

Add fakevideosink element

This is a wrapper around fakesink that will advertise GstVideoMeta
and other meta API in order to achieve zero-copy whenever possible.
his new element is useful when doing performance testing with
video stream and don't want the sink capability to change the
upstream behaviour.

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

meson: Remove unused header list

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

Fix SRT Library package config name

meson: Use .dylib suffix if darwin

For Mac OS, GST_EXTRA_MODULE_SUFFIX should be set as '.dylib'.

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

msdk: enc: Fix typo

msdk: h264_enc: Enable B-pyramid prediction support

Since there is already an "adaptive-B" option, just
use boolean property for B-pyramid enabling.

Fixme: Not sure whether this can be supported in vp8 and vp9.
It could be possible through GPB (b without backward ref) but
can't verify currently. We can move this as common property
once verified with vp8 and vp9 without breaking any backward
compatibility.

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

msdk: Add more tuning options

Added tuning options for mb level bitrate control,
adaptive I-frame insertion, and adaptive B-frame insertion.

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

msdk: h264_enc: Add slice size tuning option

According to spec, it is a general property. But based on
testing it only works for h264 encoder.
Let's keep it as h264 specific for now.

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

msdk: move enum definitions to separte file

Move enum value defintions which are (or in future) supported
by more than one codec into a common file.

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

msdk: encoder: h264: Enable trellis quantization tuning

Add a new property "trellis" to enable trellis quantization.
Keeping trellis as a flag value (which is boolean for gst x264 enc element)
since it is possible to enable/disable this seperately for
I,P and B frames through MediaSDK ext option headers.

The subclass implementations always need to inform base-encoder
if it requires the inclusion of Extend Header buffers (mfxExtCodingOption2
 and mfxExtCodingOption3).

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

msdk: h264_enc: Add LookaheadDownsampling support

This option controls down sampling in look ahead bitrate
control mode. According to spec it is only supported in AVC.

Fixme: Probably HEVC also have support for this in recent
MSDK versions. We could move the enumeration types to common
header usable for multiple codecs.

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

msdk: encode: Add more rate control options

MediaSDK has support for a number of rate control algorithms.
Adding all possible options to the property rate-control.

Fixme1: In case of failure, currently we don't have a proper method
to show which rate-control has been failed. It could be better
to add some extensive validation on EncQuery output in case of error.
Unfortunately, not all ratecontrol methods are supported by every codecs
and we don't have the dynamic detection of supported ratecontrol methods yet.

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

msdk: encode: Add property to set slice/partitioning

Adding a new property num-slices to set the number of
slices/partitions per frame. Adding it as a general
property for all codecs (except jpeg).

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

msdk: encoder: h265: generalize the behavior of "i-frames" property

We have the property "i-frames" to set the IDR interval in a
gop. Unfortunately MSDK HEVC encoder behaves bit differently
for IdrInterval field, IdrInteval == 1 indicate every
I-frame should be an IDR (which is IdrInterval == 0 for other codecs),
IdrInteval == 2 means every other I-frame is an IDR
(which is IdrInterval == 1 for other codecs) etc.
So we generalize the behaviour of property "i-frames" by
incrementing the value by one in each case (only for HEVC).

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

msdk: encoder: register only the required properties

The base encoder common properties are not valid for
mjpeg encoder where there is no motion compensation or rate control.
Delaying the property installation on the base gobject
untill the subclass class_init get invoked.

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

msdk: add missing files for dist target

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

colormanagement: Link to libgstbase for basetransform

gl: GL_LIBS does not exist anymore but X11_LIBS does and is needed

In case of X11 we have to call XInitThreads().

configure: Add configure check for gmodule-no-export-2.0

This is needed for all code using the g_module_*() API.

webrtc: We need at least libnice 0.1.14

meson.build already required that, let's do the same for configure.ac

Back to development

Release 1.13.1

Dist compositor crossfade example and pythons script for meson build

And add to autotools build so it gets disted.

configure: fix build with --disable-external

po: update translations

docs: update plugin docs

decklink: Fix array of devices usage

We need to allocate actual Device structures since we are going
to be setting callbacks with address to that structure

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

Update ORC fallback disted code

aom: Implement cpu-used in av1enc

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

pnm: Fixed segfault in pnmenc

The pnmenc was not mapping the input buffers as video buffers. Because
of this, the video frame stride was not being set based on frame but
based on the caps, which make the assumption that the strides are a
power of 4. For input that is not a power of 4, this would lead to a
SIGSEGV.

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

build: check gudev dependency for msdk plugin

gudev is the dependecy for rendernode support in MediaSDK plugin.

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

msdk: vc1_dec: Add Advanced profile (WVC1) support

Only supporting asf header-format having BDUs with startcode.
It might be possible to support other formats too, but haven't tested.

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

msdk: dec: Add non-packetized stream handling support

The gst-msdk decoders prefer packetized streams as input
and in this case we can avoid unnecessary input bitstream copy
to mfxBitstream. This works fine for codecs like h264 where
we only support byte-stream with au alignment. Other format
conversions should be done thorugh parsers. But this won't work
for codecs like vc1 where we don't have an autoplugged parser.
Even the parser is not capable to do format conversions.

Packetizing through base decoders parse() routine will bring a
lot of uncecessary of complexities and codecparser libraray dependency.
So we just use an interal gst_adaper to keep track of bitstream
which is not consumed by msdk durig AsynchronusDecoding.
This adapter will get used only if subclass implementations
set the "is_packetized" to FALSE for msdk base encoder.

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

msdk: Add VC1 decoder (simple and main profiles)

Adding Simple and Main profiles decode support.

Currently msdkvc1dec is not capable to handle the codec_data,
only instream headers are supported. Also msdk vc1 decoder
expecting instream with Sequence header as per SMPTE 421M Annex L.

Most of the decdoebin/playbin pipeline won't work with the above
constraints
because vc1parse is still not an autoplug element.

Only way to make mskdvc1dec work is by connecting a vc1parse
as an upstream element.

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

msdk : Add RenderNode support

Use drm render node as the first choice of device node file.
Fall backs to use drm primary (/dev/dri/card[0-9])
if there is no render node available

Basic logic is inherited from gstreamer-vaapi, but using
gudev API rather than libudev directly.

Added gudev library as dependency for msdk.

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

msdk: Avoid build failures on Windows until d3d allocator is implemented

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

msdkdec: use video memory if there's another MSDK context in a pipeline

1\ If downstream's pool is MSDK bufferpool,
2\ If there's shared GstMsdkContext in the pipeline,

a decoder decides to use video memory.

This policy should be improved to handle more cases.

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

msdk: add async depth from each msdk element to GstMsdkContext to be shared

In case that pipeline is like ".. ! decoder ! encoder ! ..." with using
video memory,
decoder needs to know the async depth of the following msdk element so
that it could
allocate the correct number of video memory.

Otherwise, decoder's memory is exhausted while processing.

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

msdkdec/enc: query GstContext to share GstMsdkContext

How to share/create GstMsdkcontext is the following:

- Search GstMsdkContext if there's in the pipeline.
  - If found, check if it's decoder, encoder or vpp by job type.
    - If it's same job type, it creates another instance of
GstMsdkContext
     with joined-session.
    - Otherwise just use the shared GstMsdkContext.
  - If not found, just creates new instance of GstMsdkContext.

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

msdk: context: add job type to figure out if joining session is necessary

According to the driver's instruction, if there are two or more encoders
or decoders in a process, the session should be joined by
MFXJoinSession.

To achieve this successfully by GstContext, this patch adds job type
specified if it's encoder, decoder or vpp.

If a msdk element gets to know if joining session is needed by the
shared context,
it should create another instance of GstContext with joined session,
which
is not shared.

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

msdk: adds util functions to handle GstContext

To share GstMsdkContext with each msdk element,
it will be using GstContext.

Most common code is from gstreamer-vaapi.

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

msdkdec: use bufferpool

1\ In decide_allocation, it makes its own msdk bufferpool.
  - If downstream supports video meta, it just replace it with the msdk
bufferpool.
  - If not, it uses the msdk bufferpool as a side pool, which will be
decoded into.
    and will copy it to downstream's bufferpool.

2\ Decide if using video memory or system memory.
  - This is not completed in this patch.
  - It might be decided in update_src_caps.
  - But tested for both system memory and video memory cases.

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

msdkenc: use bufferpool

1\ Proposes msdk bufferpool to upstream.
  - If upstream has accepted the proposed msdk bufferpool,
    encoder can get msdk surface from the buffer directly.
  - If not, encoder get msdk surface its own msdk bufferpool
    and copy from upstream's frame to the surface.

2\ Replace arrays of surfaces with msdk bufferpool.

3\ In case of using VPP, there should be another msdk bufferpool
   with NV12 info so that it could convert first and encode.

Calls gst_msdk_set_frame_allocator and uses video memory only on linux.
and uses system memory on Windows until d3d allocator is implemented.

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

msdk: supports bufferpool

Implements 2 memory allocators:
1\ GstMsdkSystemAllocator: This will allocate system memory.
2\ GstMsdkVideoAllocator: This will allocate device memory depending
on the platform. (eg. VASurface)

Currently GstMsdkBufferPool uses video allocator currently by default
only on linux. On Windows, we should use system memory until d3d
allocator
is implemented.

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

msdk: adds frame allocator using libva

Implements msdk frame allocator which is required from the driver.
Also makes these functions global so that GstMsdkAllocator could use
the allocated video memory later and couple with GstMsdkMemory.

GstMsdkContext keeps allocation information such as mfxFrameAllocRequest
and mfxFrameAllocResponse after allocation.

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

msdkdec: fix typo

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

msdk: implements GstMsdkContext.

Makes GstMsdkContext to be a descendant of GstObject so that
we could track the life-cycle of the session of the driver.

Also replaces MsdkContext with this one.
Keeps msdk_d3d.c alive for the future.

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

msdk: libva: adds utility function between mfx and libva

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