matroskaparse: ignore parsing errors at the end of the file

This is the same change as a3a55305 for the parser.

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

rtpbin: receive bundle support

A new signal named on-bundled-ssrc is provided and can be
used by the application to redirect a stream to a different
GstRtpSession or to keep the RTX stream grouped within the
GstRtpSession of the same media type.

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

aacparse: assertion while converting ADTS stream to RAW

aacparse resizes input buffer while converting ADTS stream to RAW,
During buffer resize buffer write permission is not checked.
This throws gst_buffer_is_writable assertion and leads to AV sync issue some times.
It is corrected by making buffer writeable using gst_buffer_make_writable

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

qtdemux: Don't modify upstream TIME segment

TIME segment implies that stream/running time is being handled by upstream.
So, we shouldn't override it without any clue.
This patch is for fixing seek in DASH streaming.

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

meson: Add define for v4l2-probe config option

deinterleave: Reset caps accumulator to ANY when resyncing the adapter, not EMPTY

The accumulator is filled by intersecting with all the pad caps, as such
it must be initialized with ANY (like it is before the iteration is
started) and not to EMPTY.

Fixes the CAPS query always returning EMPTY caps when resyncing happened
during the query, e.g. because pads were added/removed.

udpsrc: remove redundant saddr unref

The g_object_unref (saddr) before receiving message seems to be redundant as it
is done just before jumping to retry

Though not directly related, part of
https://bugzilla.gnome.org/show_bug.cgi?id=772841

udpsrc: receive control messages only in multicast

Control messages are used only in multicast mode - to detect if the destination
address is not ours and possibly drop the packet. However in non-multicast
modes the messages are still allocated and freed even if not used. Therefore
request control messages from g_socket_receive_message() only in multicast
mode.

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

Use intermediate guint when handling GstVideoMultiviewFlags

The underlying integer type of the enum GstVideoMultiviewFlags is
implementation defined and may not have the same size as guint.

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

splitfilesrc: update uri_get_type to match the prototype in GstURIHandlerInterface

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

meson: don't add_global_arguments when being built as a subproject

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

flacparse: fix header rewriting being ignored

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

flvmux: Add metadatacreator property

Allow users to set metadatacreator value in the meta packet

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

splitmuxsink: Use first buffer TS as mux start time

Do not use last buffer TS + buffer duration because buffer duration
might be inaccurate, especially for frame rates like 30fps where a
rounding error is observed.

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

rtpjitterbuffer: fix timer-reuse bug

When doing rtx, the jitterbuffer will always add an rtx-timer for the next
sequence number.

In the case of the packet corresponding to that sequence number arriving,
that same timer will be reused, and simply moved on to wait for the
following sequence number etc.

Once an rtx-timer expires (after all retries), it will be rescheduled as
a lost-timer instead for the same sequence number.

Now, if this particular sequence-number now arrives (after the timer has
become a lost-timer), the reuse mechanism *should* now set a new
rtx-timer for the next sequence number, but the bug is that it does
not change the timer-type, and hence schedules a lost-timer for that
following sequence number, with the result that you will have a very
early lost-event for a packet that might still arrive, and you will
never be able to send any rtx for this packet.

Found by Erlend Graff - erlend@pexip.com

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

rtpjitterbuffer: fix lost-event using dts instead of pts

The lost-event was using a different time-domain (dts) than the outgoing
buffers (pts). Given certain network-conditions these two would become
sufficiently different and the lost-event contained timestamp/duration
that was really wrong. As an example GstAudioDecoder could produce
a stream that jumps back and forth in time after receiving a lost-event.

The previous behavior calculated the pts (based on the rtptime) inside the
rtp_jitter_buffer_insert function, but now this functionality has been
refactored into a new function rtp_jitter_buffer_calculate_pts that is
called much earlier in the _chain function to make pts available to
various calculations that wrongly used dts previously
(like the lost-event).

There are however two calculations where using dts is the right thing to
do: calculating the receive-jitter and the rtx-round-trip-time, where the
arrival time of the buffer from the network is the right metric
(and is what dts in fact is today).

The patch also adds two tests regarding B-frames or the
“rtptime-going-backwards”-scenario, as there were some concerns that this
patch might break this behavior (which the tests shows it does not).

rtpjitterbuffer: fix bug in reschedule_timer

The new timeout is always going to be (timeout + delay), however, the
old behavior compared the current timeout to just (timeout), basically
being (delay) off.

This would happen if rtx-delay == rtx-retry-timeout, with the result that
a second rtx attempt for any buffers would be scheduled immediately instead
of after rtx-delay ms.

Simply calculate (new_timeout = timeout + delay) and then use that instead.

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

tests: wavparse: add test for processing an actual .wav file

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

wavparse: Don't set caps to NULL after setting them on the srcpad

We would like to check later on EOS if we found a known stream type or
not, to possibly post an error message.

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

qtmux: Don't deref NULL pads in debug output

That tends to crash.

isomp4: Don't use gst_video_colorimetry_to_string_full()

The API was reverted. Just use the plain
gst_video_colorimetry_to_string() function.

splitmuxsink: Fix GObject warnings on shutdown.

Commit 83e718 added a pad template to splitmux request
pads, which means that GstElement now releases the pads on
dispose, but after having removed all elements in the bin
and unlinked them. Make sure we can handle cleanup in that case
without throwing assertions.

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

splitmuxsrc: Store seek seqnum and send it on EOS / segment events.

GES relies on the EOS event having the seqnum of the seek that
caused it.

splitmuxsrc: Forward a not-linked error on the bus

Handle not-linked as for other fatal errors and post it
onto the bus so the app knows

qtdemux: Fix compiler warning

qtdemux.c: In function ‘qtdemux_parse_tree’:
qtdemux.c:10139:16: error: ‘color_table_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
             if (color_table_id != 0) {
                ^
qtdemux.c:10121:19: note: ‘color_table_id’ was declared here
           guint16 color_table_id;
                   ^~~~~~~~~~~~~~

qtmux: Use a default interleave of 250ms for all codecs

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

qtmux: Use a default interleave when ProRes is used

The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk.

It might also make sense to use similar numbers in general.

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

qtmux: Allow configuring the interleave size in bytes/time

Previously we were switching from one chunk to another on every single
buffer. This wastes some space in the headers and, depending on the
software, might depend in more reads (e.g. if the software is reading
multiple samples in one go if they're in the same chunk).

The ProRes guidelines suggest an interleave of 0.5s is common, but
specifies that for ProRes at most 2MB (for SD) and 4MB (for HD) should
be used per chunk. This will be handled in a follow-up commit.

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

qtmux: Set compressor name, horizontal/vertical resolution and depth for ProRes

This is also required by some software to handle ProRes files.

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

qt: Add support for ProRes 4444 XQ

And also 4444 in the muxer.

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

qtmux: Write 'clap' atom for ProRes

It's required for ProRes to work with other software.

It is also in the MP4 standard, but inventing values here seems a bit
tricky for the general case and it does not really give any extra
information.

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

qtdemux: Read colorimetry information from colr atom if available

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

qtmux: Always write colr atom with the colorimetry information

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

qtmux: Fix writing of the 'fiel' extension atom

This was also wrong for JPEG2000. Also write it for all MOV files and
JPEG2000, not only for ProRes.

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

qtmux: Write 4 bytes of zeroes at the end of the sample description extensions

This is working around some broken software.

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

atoms: 'pasp' atom is also part of MP4, write it always

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

qtmux: Write additional atoms for prores video

These required atoms are: colorimetry, field information, spatial/temporal
quality, and vendor.

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

rtph263depay: Don't drop mode b packets with picture start code

Some buggy payloaders, e.g. rtph263pay, may use mode B for packets
that starts with a picture (or GOB) start code although it's not
allowed. Let's be nice and not drop these packets/frames.

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

rtph263ppay: Fix caps leak

Fix leaking caps when downstream has not-fixed caps.

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

rtph263pay: Fix indentation

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

rtph263pay: Use GST_TRACE_OBJECT for logging bitstream parsing

Bump the bitstream parsing to TRACE log level so it doesn't flood the
output when trying to read the more useful DEBUG and LOG messages.

Also use GST_DEBUG_OBJECT instead of GST_DEBUG in various places

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

rtph263pay: Fix leak for B-fragments

Altough commits 6a16be7, 64f9d08 and 0c7e3a8 fixed some issues they
introduced others. This patch fixes the leak of one macroblock for every
B fragment.

Macroblock structures must not be freed immediately after finding the
boundaries as they are stored and used later. However the inital dummy
structure (used for finding the first boundary) must be freed.

CID #1212156

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

rtpbin: avoid generating errors when rtcp messages are empty and check the queue is not empty

Add a check to verify all the output buffers were empty for the
session in a timout and log an error.

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

rtpbin: pipeline gets an EOS when any rtpsources byes

Instead of sending EOS when a source byes we have to wait for
all the sources to be gone, which means they already sent BYE and
were removed from the session. We now handle the EOS in the rtcp
loop checking the amount of sources in the session.

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

rtspsrc: Also handle redirect on PLAY

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

rtspsrc: allow missing control attribute in case of a single stream

Improve RFC2326 - chapter C.3 compatibility:
In case just a single stream is specified in SDP and the control attribute
is missing do not drop the stream but rather assume "a=control:*"

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

v4l2: Warn, don't assert if v4l gives us a buffer with a too large size

I've seen problems where the `bytesused` field of `v4l2_buffer` would be
a silly number causing the later call to:

    gst_memory_resize (group->mem[i], 0, group->planes[i].bytesused);

to result in this error to be printed:

    (pulsevideo:11): GStreamer-CRITICAL **: gst_memory_resize: assertion 'size + mem->offset + offset <= mem->maxsize' failed

besides causing who-knows what other problems.

We make the assumption that this buffer has still been dequeued correctly
so just clamp to a valid size so downstream elements won't end up in
undefined behaviour.

The invalid `v4l2_buffer` I saw from my capture device was:

    buffer = {
      index = 0,
      type = 1,
      bytesused = 534748928, // <- Invalid
      flags = 8260, // V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC | V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_DONE
      field = 01330, // <- Invalid
      timestamp = {
        tv_sec = 0,
        tv_usec = 0
      },
      timecode = {
        type = 0,
        flags = 0,
        frames = 0 '\000',
        seconds = 0 '\000',
        minutes = 0 '\000',
        hours = 0 '\000',
        userbits = "\000\000\000"
      },
      sequence = 0,
      memory = 2,
      m = {
        offset = 3537219584,
        userptr = 140706665836544, // Could be nonsense, not sure
        planes = 0x7ff8d2d5b000,
        fd = -757747712
      },
      length = 2764800,
      reserved2 = 0,
      reserved = 0
    }

This is from gdb with my own annotations added.

This was with gst-plugins-good 1.8.1, a Magewell XI100DUSB-HDMI video
capture device and kernel 3.13 using a dodgy HDMI cable which is great at
breaking HDMI capture devices.  I'm using io-mode=userptr and have built
gst-plugins-good without libv4l.

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

qtmux: Use a better default value for the movie header timescale

Take the maximum video timescale, or if no video track is present the
previous value of 1800.

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

qtmux: Be more clever with the default video track timescale

Use the number of milliframes per second for integral and drop-frame
framerates, as suggested by the QT file format specification and other
places. We already did that for integral framerates before, but not for
drop-frame framerates. This now keeps precision better.

For all other framerates, check if it's close to a well-known framerate
and use that instead.

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

qtdemux: extract interlaced information from jpeg video

This information is hidden in a small chunk of data.
Format found at https://developer.apple.com/standards/qtff-2001.pdf,
page 92, "Video Sample Description", under table 3.1.

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

gdkpixbufoverlay: Fixing x and y offset computation

While computing the x and y offsets, it's the video resolution and
resized overlay resolution to be used instead of actual overlay image
resoltuion. Due to this, the overlay image used to get wrongly overlayed
in undesired location

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

meson: update version

qtdemux: Use the tfdt decode time on byte streams when it's significantly different than the time in the last sample

We consider there's a sifnificant difference when it's larger than on second
or than half the duration of the last processed fragment in case the latter is
larger.

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

Back to development

Release 1.10.0

Update .po files

po: Update translations

v4l2object: fix extra-controls leak

Gst struct v4l2object->extra_controls is created if user sets appropriate
option but it is not freed on destruction of v4l2object.

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

Revert "souphttpsrc: reduce reading latency by using non-blocking read"

This reverts commit 8816764112408766889c8b680a3af51115df4bf5.

It causes issues with the timeouts, and causes connections to be closed
without actual reason. Needs further investigation.

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

wavparse: Don't try to add srcpad if we don't know valid caps yet

Otherwise we'll run into an assertion on specially crafted files.

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

meson: Remove uselessly duplicated dep checks

These checks are done inside the meson.build files for each plugin.

meson: dv plugin now works on MSVC

Needs a Meson patch to filter out the useless -lpthread

https://github.com/mesonbuild/meson/pull/962

matroskamux: allow resolutions above 4096

Modify the caps string to allow width and height greater than 4096.
There is no need to restrict it since the matroska format allows the
width and height values to be up to eight bytes long.

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

udpsrc: Check for G_PLATFORM_WIN32 for presence of ipi_spec_dest

G_OS_WIN32 is only set when not building with cygwin, but
ipi_spec_dest is missing both with and without cygwin.

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

souphttpsrc: reset read_position when reading fails

souphttpsrc maintains two variables for the position:
 * 'request_position' is where we want to be
 * 'read_position' is where we are
During Normal operations both are updated in sync when data arrives. A seek
changes 'request_position' but not 'read_position'.
When the two positions get out of sync, then a new request is send and the
'Range' header is adjusted to the current 'request_position'.

Without this patch, if reading fails, then the source is destroyed. This
triggers a new request, but the range remains unchanged. As a result, the
old range is used and old data will be read.

Changing the 'read_position' to -1 makes it explicitly different from
'request_position' and as a result the 'Range' header is updated correctly.

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

meson: Don't depend on gstreamer-check-1.0 on windows

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

rtspsrc: reset connection info to non-flushing when closing

This solves a hanging mainloop in following scenario:
* connect to source
* network/server drops
* pipeline set to NULL (and connection to flushing as part)
* pipeline set to PAUSED/PLAYING (connection to non-flushing, but not recorded)
* [connecting still not possible]
* pipeline set to NULL => mainloop hangs (since no actual flushing is done)

splitmuxsink: Only allow one video request pad

The pacing of the overall muxing is controlled
by the video GOPs arriving, so we can only handle
1 video stream, and the request pad is named accordingly.

Ignore a request for a 2nd video pad if there's already
an active one.

splitmuxsink: Take ownership of floating refs

sink the floating ref when handed a muxer or sink to use so
we clearly take ownership.

splitmuxsink: Set child elements to NULL when removing.

Make sure that elements are in the NULL state when removing.
Fixes critical warnings when errors occur early on in starting up.

splitmuxsink: Set pad template on request sink pads

Ensure that the ghost pad returned as a request pad
has the template that was requested

Revert "meson: move gstreamer-check-1.0 dependency to tests/check"

This reverts commit 46632694662b96fddb848a1f2091a215b28a2d35.

Does not actually work. See:
https://bugzilla.gnome.org/show_bug.cgi?id=773114#c31

flvmux: Assume PTS is DTS when PTS is missing

This fixes issue for encoders that only sets the DTS. We assume that
there was no re-ordering when that happens.

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

meson: fix build outside of gst-all

meson: directsound: Add ole32 library dependency

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

meson: move gstreamer-check-1.0 dependency to tests/check

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

tests: videomixer: disable racy flush_start_flush_stop test

It's been broken for years, and it's unlikely it will ever
be fixed for collectpads/videomixer now that there's compositor
which works fine. So let's disable it, since all it does
is that it creates noise that distracts from other failures.

Also see the corresponding adder bug as it failed in the same way:
 https://bugzilla.gnome.org/show_bug.cgi?id=708891

tests: Fix souphttpsrc tests without CK_FORK=no

It seems that the forked processes all attempt to handle the listening
socket from the server, and only one has to shutdown the socket to break
the server completely.

Create a new server inside each test to avoid this.

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

tests: Fix level test in CK_FORK=no mode

The tests accumulate buffers in GstCheck's buffers list, and the list is
not (consistently) reset between tests. Do that and remove the now
conflicting unrefs for outbuffers.

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

waveformsink: Fix Memory leak using GST_PTR_FORMAT

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

meson: Add missing gstaudio dep to monoscope

In file included from ../subprojects/gst-plugins-good/gst/monoscope/gstmonoscope.c:42:0:
../subprojects/gst-plugins-base/gst-libs/gst/audio/audio.h:26:39: fatal error: gst/audio/audio-enumtypes.h: No such file or directory
 #include <gst/audio/audio-enumtypes.h>
                                       ^
compilation terminated.

https://ci.gstreamer.net/job/GStreamer-master-meson/271/console

meson: Add missing pbutils dependency to multifile

Found via the Jenkins CI:

FAILED: subprojects/gst-plugins-good/gst/multifile/gstmultifile@sha/gstsplitmuxsink.c.o
[...]
In file included from ../subprojects/gst-plugins-good/gst/multifile/gstsplitmuxsink.h:24:0,
                 from ../subprojects/gst-plugins-good/gst/multifile/gstsplitmuxsink.c:59:
../subprojects/gst-plugins-base/gst-libs/gst/pbutils/pbutils.h:30:43: fatal error: gst/pbutils/pbutils-enumtypes.h: No such file or directory
 #include <gst/pbutils/pbutils-enumtypes.h>
                                           ^
compilation terminated.

https://ci.gstreamer.net/job/GStreamer-master-meson/263/console

meson: Don't set c_std to gnu99

Use the default for each compiler on every platform instead. This
improves our compatibility with compilers that don't have gnu99 as
a c_std.

meson: Make use of new environment object and set plugin path to builddir

Workaround source_root being the root directory of all projects in the subproject
case and remove now unneeded getpluginsdir

Bump meson requirement to 0.35

tests: Fix memory leak in test rtpaux test

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

imagefreeze: Forward latency queries to upstream

Without this, latency queries to imagefreeze will fail.

meson: Setup pre commit hook and fix getpluginsdir for standalone case

splitmuxsrc: Handle stop point from segment

If the seek stop point (or start, during reverse play)
was within the segment we just finished, go EOS immediately
instead of proceeding through all other parts and sending
0 length seeks to them.

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

splitmuxsrc: Drop lock shutting down pads

Avoid a sporadic deadlock on shutdown by dropping
the splitmux lock around pad shutdown

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

splitmuxsrc: Fix extra unref handling queries

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

splitmuxsrc: Avoid stall when parts get out of sync

When one part moves ahead of the others - due to excessive
downstream queueing, or really small input files - then
we can end up activating parts more than once. That can lead to
effects like shutting down pad tasks prematurely.

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

meson: update version

Release 1.9.90

Update .po files

po: Update translations

tests: Fix tagschecking failure due to missing PTS

qtmux now needs the PTS (commit a993883b7), so let's make sure we
produce one with our buffers.

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

qtmux: Don't calculate PTS offset and DTS with GST_CLOCK_TIME_NONE

Just error out if there is no valid PTS.

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

qtdemux: Add JPEG2000 ihdr atom to the list of known ones

Otherwise qtdemux is always going to complain about it being unknown.

matroskamux: Always write the default frame duration for VP8/9 too

The WebM spec allows this now, and it allows us to guess a framerate.

See https://bugzilla.gnome.org/show_bug.cgi?id=772141 and
also https://bugzilla.gnome.org/show_bug.cgi?id=654379

rtph26[45]depay: Don't handle NALs inside STAP units twice

They've already been handled before pushing them into the adapter.