Especially in force-live=true mode it was possible to produce buffers before the
element was set to PLAYING as long as a clock was available already.
This could easily lead to outputting buffers too early, and e.g. before the
correct base time is set and available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8897>
This doesn't always bring visible issue, but is formally incorrect:
not chaining up means that the code doesn't trigger GstObject and
GstElement "constructed" implementations.
In particular both GstElement's and GstObject's classes in
"constructed" may sign up this object for tracing and
GstObject's class sets GST_OBJECT_FLAG_CONSTRUCTED flag.
If we don't chain up none of this is going to be executed.
For example, before the fix leaks tracer couldn't detect this leak:
```c
int main (int argc, char **argv) {
g_setenv ("GST_TRACERS", "leaks(name=all-leaks)", TRUE);
g_setenv ("GST_DEBUG", "GST_TRACER:7", TRUE);
g_setenv ("G_DEBUG", "fatal-warnings", TRUE);
gst_init (&argc, &argv);
// leak audiomixer: doesn't detect because it's based on the aggregator
gst_element_factory_make ("audiomixer", "Jerry");
// leak videoconvert: this one is detected fine because it's not
// based on the aggregator
//gst_element_factory_make ("videoconvert", "Tom");
gst_deinit ();
return 0;
}
// $ cc tst.c $(pkg-config --cflags --libs gstreamer-1.0) -o tst && ./tst
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8416>
If starting the internal clock fails we would still store a broken clock in the
cache despite it being unusable and never recovering.
Not storing it allows the application to simply create a new one at a later time
and have starting it retried.
Also signal to the application that such a clock is not synced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8334>
With this patch, configure time is identical no matter whether doc is
enabled or not.
The configuration files also now contain explicitly-listed sources with
no wildcards.
For the four libraries where hotdoc needs to use clang to generate the
documentation (as opposed to the rest of the libraries where hotdoc uses
the gir), the script will call pkg-config to determine the appropriate
C flags.
This means a side effect of this patch is that pkg-config files are now
generated for the gstadaptivedemux and gstopencv libraries.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8312>
When force-live is TRUE, aggregator will correctly change its state with
NO_PREROLL, but unless something upstream is live did not previously set
live to TRUE on the latency query.
Fix this by or'ing force_live into the result.
Also improve debug
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7718>
This reverts commit 779e715b6cee4f7793c43a0e78c6106ab66f1032.
Since the introduced corrupt clock state for when discovering a time
server restart, this resulted in previous similar check as done in
this patch became ignored/jumped over (in case of the corrupt state
has been noticed).
Reference: df41d11a7d7f844e593a10f6a6a0858333fbf7ec
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
Clients that already gotten a signal for synced clock, may rely on
getting the same when marked as corrupted to take appropriate action. So
send clock signal indicating no sync at identified corrupted state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7664>
An application that triggers a state transition from PLAYING to PAUSED
needs to acquire the LIVE_LOCK. Consequently the LIVE_LOCK must not be
taken while pushing anything on the pads because this operation might
get blocked by something that cannot be unblocked without the
application being able to proceed with the state transitions for other
elements in the pipeline. This commit extends the previous behaviour
where the live lock was released before pushing buffers (indirectly
through the unlock before subclass->create) to now also include
unlocking before pushing events.
The issue was discovered in a case for WebRTC where the application
tried to shut down a pipeline but an event originating from a video
source element (based on basesrc) was in the process of being pushed
down the pipeline when it got stuck on the STREAM_LOCK for the pad after
the rtpgccbwe element. This lock in turn was held by the rtcpgccbwe
element as it was in the process of pushing data down the pipeline but
was stuck on the blocking probes installed on dtlssrtpenc to prevent
data from flowing before dtls keys had been negotiated. What should have
happened here is that the blocking probes should be removed, but that
can only happen if the application may continue driving the state
transitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6671>
And handle the case of a NULL buffer being returned cleanly, which is
valid as long as a buffer list is returned instead. Previously this
would cause an assertion because of calling gst_buffer_unref() with
NULL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6460>
The attempt to free the domain data is happeing twice during the ptp deinit.
Once while iterating through the list domain_data and second while iterating
through the list domain_clocks, so this is crashing the application
trying to gst_ptp_deinit
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6443>
On systems using UsrMerge (like openSUSE or Fedora), /lib64 is
a symlink to /usr/lib64. So dladdr is returning the path to
the gstreamer library in /lib64 in priv_gst_get_relocated_libgstreamer.
Later gst_plugin_loader_spawn tries to build the path to the
gst-plugin-scanner helper from /lib64 and ends up trying to use
/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner which doesn't exist.
By canonicalizing the path with a call to realpath, gst-plugin-scanner
is found correctly under
/usr/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
Similar change applied to gstreamer/libs/gst/net/gstptpclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6322>
