GitLab

* Implement the GstURIHandlerInterface
* Rework the locking
* Implement backward seeking handling
* Generate documentation

See: gstreamer/gst-plugins-good#121

Lower the verbosity of the 'sync' log message emitted
each buffer from gst_v4l2src_create down to LOG(6)
from INFO(4). This brings the logging behavior of
v4l2src closer to the GStreamer guidelines, which
recommend the INFO level be reserved for rare or
one-off messages.

The caps received from qtdemux for AC-4 content are audio/x-gst-fourcc-ac_4

Based on patch by: Savinderjit Kaur

Fixes gstreamer/gst-plugins-good#413

Ignore the return value of gst_pad_set_caps() so that setcaps will set a
framerate that is usable.

Fixes gstreamer/gst-plugins-good#705

They will be repropagated anyway.

- Refactored the planar transform method to support all video formats
  that are stored planar, independent of the used subsampling
- Added support for Y444

gst_buffer_map () results in memcopying when a GstBuffer contains
more than one GstMemory and when AVC (length-prefixed) alignment is used.
This has quite an impact on performance on systems with limited amount of
resources. With this patch the whole GstBuffer will not be mapped at once,
instead each individual GstMemory will be iterated and mapped separately.

By explictly including QtGui/qopengl.h we force the code path that
defines GLsync in the Qt-specific way. Without that, some platforms
failed to compile the qmlgl plugin, since neither Qt nor gstreamer
defined GLsync then, leading to e.g.:

```
make[4]: Entering directory '/.../gst-plugins-good-1.16.1/ext/qt'
  CXX      libgstqmlgl_la-qtitem.lo
In file included from gstqtgl.h:32,
                 from qtitem.h:27,
                 from qtitem.cc:28:
/.../usr/include/gstreamer-1.0/
gst/gl/gstglfuncs.h:93:17: error: expected identifier before ‘*’ token
   ret (GSTGLAPI *name) args;
                 ^
/.../usr/include/gstreamer-1.0/
gst/gl/glprototypes/sync.h:27:1: note: in expansion of macro
‘GST_GL_EXT_FUNCTION’
 GST_GL_EXT_FUNCTION (GLsync, FenceSync,
 ^~~~~~~~~~~~~~~~~~~
```

When calling gst_rtp_jitter_buffer_reset you pass in a seqnum.

This is considered the starting-point for a new stream.

However, the old behavior would unref this buffer, basically lying to
the thread that is pushing out buffers saying that it can expect
this buffer, when it would never arrive. The resulting effect being no
more buffer pushed out of the jitterbuffer, and it would buffer
incoming data indefinitely.

By instead inserting the buffer in the gap_packets queue, the _reset()
function will take responsibility for using that as the first buffer
of the new stream.

Fixes #703

In order to concatenate fragments, splitmuxsrc offsets
the start of each fragment PTS to 0 to align it with the
previous file. This means that DTS can go negative for
the first fragment, with really bad results.

Add a fixed offset to outgoing timestamp ranges to
avoid that.

Vanilla mono video was generating a spurious warning into the debug log
that's just misleading. Handle mono caps explicitly to avoid the warning.

In this mode each field is carried using its own buffer.
Allow deinterlace to negotiate caps with the Interlaced feature and
adjust the algorithm fetching lines.

Fix #620

No semantic change so far, will be used to implement alternate support.

The LINE2() macro already prevents out of bound indexes using CLAMP_HI()
and CLAMP_LOW().

Output frames used to have their interlace mode set to the same one as
the input. This breaks their field and comp heights when deinterlacing
an alternate stream.

In interlace-mode=alternate the input buffers have half the size of the
output ones as each field has its own buffer.

Each FLAC metadata block starts with a flag denoting whether it is the
last metadata block. The existing flacparse code moves any existing
VORBISCOMMENT block to immediately follow the STREAMINFO block without
changing any block's last-metadata-block flag. If no VORBISCOMMENT block
exists, it created one with the last-metadata-block flag set to true.
This results in gstflacdec sometimes giving bad headers to libflac when
trying to play perfectly valid FLAC files depending on the file's
metadata ordering. Depending on the contents of the other metadata
blocks, current versions of libflac may or may not return
FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER when given this broken
metadata. This is most noticeable with files that have a large cover art
image attached where VORBISCOMMENT is the very last metadata block with
no PADDING afterwards.

This patch changes that behavior so that:

1. For FLAC files that already have a VORBISCOMMENT block, the metadata
   order is preserved.
2. For FLAC files that do not have a VORBISCOMMENT block, the generated
   dummy VORBISCOMMENT is placed immediately after STREAMINFO and
   inherits the last-metadata-block flag from STREAMINFO.

gstreamer/gst-plugins-good#484

When using the testclock for determining clock in test, it is sometimes observed
that the clock entry is not registered in time by the aggregator. So deadlock occurs
between the aggregator and the test thread.

qtdemux: Try to infer useful header values for raw audio if the sound sample descriptions contain zero values

Previously it was only used for in24.

Sometimes the headers contain useless, wrong or zero values for e.g. the
sample size with these formats. There's only a single valid value for
them so let's set these instead.

We do not have a way to know the format modifiers to use with string
functions provided by the system. G_GUINT64_FORMAT and other string
modifiers only work for glib string formatting functions. We cannot
use them for string functions provided by the stdlib. See:
https://developer.gnome.org/glib/stable/glib-Basic-Types.html#glib-Basic-Types.description

```
../gst/rtpmanager/gstrtpjitterbuffer.c: In function 'gst_jitter_buffer_sink_parse_caps':
../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: unknown conversion type character 'l' in format [-Werror=format=]
           || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1)
                                ^~~~~~~~~~
In file included from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/gtypes.h:32,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/galloca.h:32,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib.h:30,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/gst.h:27,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/rtp/gstrtpbuffer.h:27,
                 from ../gst/rtpmanager/gstrtpjitterbuffer.c:108:
/home/nirbheek/cerbero/build/dist/windows_x86/lib/glib-2.0/include/glibconfig.h:69:28: note: format string is defined here
 #define G_GUINT64_FORMAT "llu"
                            ^
../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: too many arguments for format [-Werror=format-extra-args]
           || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1)
                                ^~~~~~~~~~
```

See also: gstreamer/gstreamer!379

Usually something else is pulling it in somehow already, but not on
Windows.

Previously we saved the buffer_timestamp straight into
mux->cluster_time. Since the cluster time saved into the file does not
have as high precision as GstClockTime depending on the timecodescale
the rounding of relative_timestamp was invalid as mux->cluster_time
which it was calculated relative to was not equal to the cluster time
written to the matroska file.

Example of "mkvinfo -v" of how it looks before and after this change in
an scenario where previously timestamps got out of order because of this
issue.

Notice the timestamp of the SimpleBlock right before and right after the
Cluster now being in order. The consequence of this however is that the
cluster timestamp is not necessarily the same as the timestamp of the
first buffer in the cluster however (in case it's rounded up).

Before

| + SimpleBlock (track number 1, 1 frame(s), timecode 126.922s = 00:02:06.922)
|  + Frame with size 432
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.933s = 00:02:06.933)
|  + Frame with size 329
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.955s = 00:02:06.955)
|  + Frame with size 333
|+ Cluster
| + Cluster timecode: 126.954s
| + Cluster previous size: 97344
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 126.954s = 00:02:06.954)
|  + Frame with size 61239
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.975s = 00:02:06.975)
|  + Frame with size 338

After

| + SimpleBlock (track number 1, 1 frame(s), timecode 135.456s = 00:02:15.456)
|  + Frame with size 2260
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.468s = 00:02:15.468)
|  + Frame with size 332
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.490s = 00:02:15.490)
|  + Frame with size 335
|+ Cluster
| + Cluster timecode: 135.489s
| + Cluster previous size: 158758
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 135.490s = 00:02:15.490)
|  + Frame with size 88070
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.511s = 00:02:15.511)
|  + Frame with size 336

Disable session sharing and cookie jar when cookies property is set.

The cookie jar actually replaces or removes any existing Cookie header
set on the message, so the cookies property was effectively being
ignored. There doesn't appear to be a way to inject the cookies into the
jar without having to specify matching domains etc., so it's not
possible to simulate the old behaviour of unconditionally sending the
cookies with all messages, besides simply disabling the cookie jar.

Comparing gst_rtspsrc_loop_interleaved and gst_rtspsrc_loop_udp, and investigating on timeout issues, it sounds like a piece of code has been originally copied from udp to the interleaved one. The timeout variable is never used inside the interleaved one. No side effect has been seen in the removed function calls.

The debug message removed is pointless as the timeout used is "src->tcp_timeout" that is fixed.

The presence of the two timeout drove my team in investigating if the reference to the tcp_timeout was correct (it is). Hence we removed the misleading reference to the local timeout variable.

we were setting the max-dropout-time to the value of the
max-misorder-time which by default has a factor of 30 difference in
value.