This is a bug in LuminOS 0.97.0.

mlaudiosink: Add support for spatial sound

mlaudiosink: Use recommended size

TMP

Android documentation has example code how to compute width and height
when crop values are present.
https://developer.android.com/reference/android/media/MediaCodec#accessing-raw-video-bytebuffers-on-older-devices

Magical 0/1 values where passed to gst_amc_codec_configure() flags
argument. It's more natural to have a boolean is gst_amc_codec_new().

It is not needed, we can just try to get the key and ignore error.
NdkMediaFormat doesn't have that method.

There is no NdkMediaCodecList API yet, but it is still better to isolate
JNI code. This will facilitate porting to a native API if Google ever
release one.

This will facilitate adding another implementation based on
NdkMediaCodec instead of JNI.

Seungha Yang authored Apr 09, 2019 and Xavier Claessens committed Sep 09, 2019

crypto libraries are not required for hlssink and hlssink2.
Also, hlsdemux with nonencrypted stream can work without crpyto.

Make an error only when users set "hls-crpyto" with non-auto option explicitly,
but no crpyto library was found.

Askar Safin authored Sep 04, 2019 and Tim-Philipp Müller committed Sep 06, 2019

Fix gst_event_new_seek call in gst-libs/gst/player/gstplayer.c

If rate >= 0.0, then previous code doesn't set end of segment. So, the end of segment
will be in place where previous seek put it. This is not neccesary end of media file
(in case of reverse playback). So if we play video backward for some time and then
switched to forward playing, we will get EOS somewhere in the middle of media file.
This commit always sets end of segment, thus fixing this bug

Matthew Waters authored Aug 21, 2019 and Tim-Philipp Müller committed Sep 02, 2019

Asking decklink to render audio data seems to be based entirely on
the sample counts which completely disregards the timestamps
we pass to decklink.  As a result, we need to explicitly check
for late buffers and drop them ourselves.

Instead of using the information we stored ourselves for the video frame
itself. Which was also the wrong one: it was the mode from the property,
not the autodetected one.

This fixes vanc extraction with mode=auto

Olivier Crête authored Aug 23, 2019 and Tim-Philipp Müller committed Sep 01, 2019

Just use srt's blocking epoll function and fix locking while we're at it.

Gauthier Lamaison authored Aug 20, 2019 and Tim-Philipp Müller committed Aug 23, 2019

Do not take device_name if a device has been specified. Do not take device_index into account if a device or a device name has been specified.

Jan Schmidt authored Jun 28, 2019 and Tim-Philipp Müller committed Aug 21, 2019

PES packets with size 0 are unbounded, and
could therefore overflow the 32-bit size
accumulator.

Add a 32MB limit, which is larger than
any PES packet should ever get. If one does,
then output a 32MB chunk and continue.

Nirbheek Chauhan authored Aug 20, 2019 and Tim-Philipp Müller committed Aug 20, 2019

On Windows, if libusrsctp and gstreamer are built with different
C runtimes (CRT), we cannot free memory allocated inside libusrsctp
with the `free()` function from gstreamer's CRT.

`usrsctp_freedumpbuffer()` simply calls `free()`, but because of the
way DLLs work on Windows, it will always call the free function from
the correct CRT.

Niels De Graef authored May 09, 2019 and Tim-Philipp Müller committed Aug 20, 2019

Some GIR annotations were incorrect or even missing. The former isn't
good for bindings, while the latter is especially annoying for signal
handlers, as that means your arguments will get the wrong names in the
rendered documentation.

Matthew Waters authored Aug 14, 2019 and Tim-Philipp Müller committed Aug 20, 2019

A guint32 greater than 2^31 would be interpreted as negative by
gst_util_uint64_scale_int() and critical. Use the 64-bit integer version
of the function instead.

librtmp is always built with MinGW in Cerbero, so if the plugin is
built with MSVC and it frees memory allocated by librtmp, that leads
to a crash since the CRT used by MinGW and MSVC are different.

This is fixed in master by switching to a newer GCC toolchain which
has been configured to use the same CRT as newer versions of Visual
Studio, so there's no cross-CRT memory alloc/free issues.

See: gstreamer/cerbero#164

Seungha Yang authored Aug 15, 2019 and Tim-Philipp Müller committed Aug 16, 2019

... caused by null pointer dereference. The d3dvideosink object might
not available yet on the handler.

Xavier Claessens authored Aug 14, 2019 and Tim-Philipp Müller committed Aug 14, 2019

_amc_gl_free() could be called after the GstAmcVideoDec has been
finalized, in the case downstream still has a ref to a buffer.

Doug Nazar authored Aug 09, 2019 and Tim-Philipp Müller committed Aug 14, 2019

The various soundtouch set*() functions may cause buffer (re)allocations
which interferes with inputting the audio data.

Sebastian Dröge authored Aug 12, 2019 and Tim-Philipp Müller committed Aug 13, 2019

It's found like this in various files out there even if it does not
conform to SMPTE 2019-4.

Sebastian Dröge authored Aug 06, 2019 and Tim-Philipp Müller committed Aug 12, 2019

decklinkaudiosrc/decklinkvideosrc: Do nothing in BaseSrc::negotiate() and always set caps in ::create()

We don't support negotiation with downstream but simply set caps based
on the buffers we receive. This prevents renegotiation to other formats,
and negotiation to NTSC in mode=auto in the beginning until the first
buffer is received.

As side-effect of this, also remove various other caps handling code
that was working around the behaviour of the default
BaseSrc::negotiate().

This reverts commit 6c8831bd from !588

This fix was wrong and also reverted in master.`