GitLab

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

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

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)

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.

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

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

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

This reverts commit 46632694.

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

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

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

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

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

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

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

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

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

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

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.

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

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

Without this, latency queries to imagefreeze will fail.

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

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

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

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

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

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

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

Just error out if there is no valid PTS.

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

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

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

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

Those variables are not defined if vp8 was not found.

This reverts commit f1ceaab0.

This broke atomic file writes in "buffer" mode. It did make
sure that any streamheaders are prepended to each file in
buffer mode as well, but that's not really needed in practice,
whereas atomic file writes are, so let's restore the status
quo ante for now since this was primarily a code cleanup anyway,
and if anyone needs to streamheaders in buffer mode too they
can make a patch to implement that differently. Re-implementing
the atomic writes in the element also seems way too much work.

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

This reverts commit 84e441d2.

This will no longer be needed once we revert f1ceaab0.