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
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
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
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
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.
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
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
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
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
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
