They are part of gst_dep already and we have to make sure to always have
gst_dep. The order in dependencies matters, because it is also the order
in which Meson will set -I args. We want gstreamer's config.h to take
precedence over glib's private config.h when it's a subproject.
While at it, remove useless fallback args for gmodule/gio dependencies,
only gstreamer core needs it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2031>
When building for Android, chances are that gstreamer is going to be
loaded from Java using System.loadLibrary(). In that case we can
initialize GStreamer (including static plugins), redirect log functions,
etc.
This code is copied from cerbero because it can be used with
gstreamer-full-1.0 too. Cerbero needs to be adapted to drop that code
and generate gst_init_static_plugins() function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/617>
The documentation for several gst_*_writable_structure functions stated
that they would never return NULL, without making clear that the passed
object is required to be writable. This changes the wording in those
cases to make that requirement more clear.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1784>
This commit modifies the interleave calculation to allow growing when incoming
data is before the segment start.
The rationale is that there is no requirement whatsoever for data before the
segment start to be "coherent" on all streams.
For example, a demuxer could rightfully send data from the video stream from the
previous keyframe (potentially quite a bit before the segment start) and the
audio from just before the segment start.
This will activate the same logic as growing the interleave when some streams
haven't received buffers yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1892>
* When a stream receives EOS, it will no longer change, we shouldn't take that
stream into account for interleave calculation.
* When streams (re)appear, we do not want to grow the initial interleave values
to excessive values. Instead of setting it to a default of 5s, progressively
grow it to that maximum.
* When the status of input streams change (i.e. going to/from "some haven't
received data yet" and "all have received data"), update the interleave
immediately instead of waiting for (potentially) 5s of data before updating
it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1892>
Fix suppression to support release and debug builds.
Here is the debug build call stack:
```
==10707== by 0x48B5520: g_malloc (gmem.c:106)
==10707== by 0x48D19DC: g_slice_alloc (gslice.c:1069)
==10707== by 0x48D3947: g_slist_copy_deep (gslist.c:619)
==10707== by 0x48D38B8: g_slist_copy (gslist.c:567)
==10707== by 0x4ADC90B: gst_debug_remove_with_compare_func (gstinfo.c:1504)
```
In release build `g_slist_copy (gslist.c:567)` got inlined:
```
==15419== by 0x48963E0: g_malloc (gmem.c:106)
==15419== by 0x48AA382: g_slice_alloc (gslice.c:1069)
==15419== by 0x48AB732: g_slist_copy_deep (gslist.c:619)
==15419== by 0x4A39B8F: gst_debug_remove_with_compare_func (gstinfo.c:1504)
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1814>
Remove the symbolic link `gst-uninstalled` which points to `gst-env`.
The `uninstalled` is the old name and the project should stick to a
single name for the procedure.
Remove the term from all the files, exceptions are variables from
dependencies like `uninstalled_variables` from pkgconfig and
`meson-uninstalled`.
Adjust mentions of the script in the documentation and README.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
Do not maintain similar build instructions within each gst-plugins-*
subproject and the subproject/gstreamer subproject. Use the build
instructions from the mono-repository and link to them via hyperlink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1743>
Scenario:
- Source 1 requesting and waiting a clock id
- Source 2 requesting and waiting on a clock id
- Test attempting to crank both sources in the same GstHarness
gst_test_clock_crank() originally dropped locks between the retrieving
of the next clock id and advancing to the next clock id. This would
mean that both sources would race each other attempting to complete
their clock waits. Sometimes the operations would be performed in the
correct order, other times they would not and a FALSE return value would
be produced.
This would lead to an assertion in gst_harness_push_from_src() expecting
that all clock cranks to succeed.
Fix by ensuring that the clock wait produced is dealt with before
processing the next by not dropping the relevant locks after retrieving
the next clock id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1299>
There's no need to do this, and it can make seeking far less accurate.
For a specific use case: I am working with a long (45-minute) MPEG-1 layer 3 file, which has a constant bit rate but no seeking tables. Trying to seek the pipeline immediately after pausing it, without the ACCURATE flag, to a location 41 minutes in, yields a location that is potentially over ten seconds ahead of where it should be. This patch improves that drastically.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/374>
During dispose the pool will still have a reference count of 1 and all
API on it can still be safely called.
Subclasses will have already freed their own data before finalize is
called but would nonetheless be called into again via the pool
deactivation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1645>
Those will cause us to renegotiate at the next aggregate cycle,
and while at that point we may decide to reconfigure upstream
branches (in practice we don't as this is inherently racy,
and that's the reason why mixer subclasses perform conversion
internally), we certainly don't want to just forward the event
willy-nilly to all our sinkpads.
An actual issue this is fixing is when caps downstream of a
compositor are changed at every samples-selected signal emission,
for the purpose of interpolating the output geometry, and the
compositor has a non-zero latency, the reconfigure events were
forwarded to basesrc, which triggered an allocation query, which
in turn caused aggregator to have to drain (thus not being able
to queue <latency> frames), leading to disastrous effects
(choppy output as compositor couldn't consume frames fast enough,
the higher the latency the choppier the output)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1464>
