Below fallback paths were introduced in
9759810d82
if setting period time after buffer time failed :
1) Set period time and then buffer time if it doesn't work
2) Set only buffer time
3) Set only period time
These all were not functioning properly since they were using old
copy of snd_pcm_hw_params_t which already had some fields set
as per previous try and this was causing issues as driver was
referring to that old value while trying to set them again in
fallback paths.
So now we always use the initial copy of snd_pcm_hw_params_t
for every fallback and same is also being done at
557c429510
Also we change the sequence to set period time earlier than
buffer time since period bytes being the smaller unit, most of the times
if underlying alsa device has a dependency then it is of period bytes
to be a multiple of some value (as per underlying DMA constraint)
and rest of the parameters like buffer bytes need to be adjusted
as per period bytes.
The same sequence is also followed in alsa-utils at
9b621eeac4
Fix 2) and 3) scenarios by returning success if the exclusive setting is passed
and not doing any further setting for buffer time or period time.
Add new fallback path of not setting any buffer time and period time
if all above fallback paths fail. The same is also being
followed at aforementioned pulseaudio commit.
In case of alsasink, remove the retry goto label, since it is not
required anymore as fallback paths take care of setting default
values if driver is not accepting any of the fallback paths.
Use separate label for exit to free params structs and return err
code. This also fixes leak in no_rate goto path in alsasink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1212>
When connecting to an RTSP server in tunnled mode (HTTP) the server
usually replies with a x-server header. This contains the address
of the intended streaming server. However some servers return an
"invalid" address. Here follows two examples when it might happen.
1. A server use Apache combined with a separate RTSP process to handle
Https request on port 443. In this case Apache handle TLS and
connects to the local RTSP server, which results in a local
address 127.0.0.1 or ::1 in the x-server reply. This address is
returned to the actual RTSP client in the x-server header.
The client will receive this address and try to connect to it
and fail.
2. The client use a ipv6 link local address with a specified scope id
fe80::aaaa:bbbb:cccc:dddd%eth0 and connects via Http on port 80.
The RTSP server receives the connection and returns the address
in the x-server header. The client will receive this address and
try to connect to it "as is" without the scope id and fail.
In the case of streaming data from RTSP servers like 1. and 2. it's
useful to have the option to simply ignore the x-server header reply
and continue using the original address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1192>
We shouldn't fail to load plugins just because we don't
recognise the license string. It's not our job to validate
licenses, and the license list is outdated and ambiguous
anyway.
Also add MPL-2.0 to the list, and fix some defunct license
URLs in the code comments.
Get rid of the hard-coded skip index, doesn't really buy us
much versus just skipping with a few strlens, and is harder
to maintain.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/864>
Requires OpenGL 4.4 or EXT_buffer_storage
Current mesa exposes GL_ARB_buffer_storage when retrieving the relevant
functions returns no-ops and causes failures.
Improves throughput of uploads by roughly 30%-60% and download throughput by
roughly 10-30% across depending on the exact scenario and hardware.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1191>
Default timer precision of Windows is dependent on system, but
usually it's known to be about 15ms in worst case.
That's not an enough precision for multimedia application.
Enable high-resolution clock in gst-launch to demonstrate
the usage of Windows high-precision clock for application developers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/817>
Normally uri is get from user input and invalid user input should not
be treated as critical error. Moved gst_uri_is_valid outside of
g_return_val_if_fail.
NULL uri is checked inside of gst_uri_is_valid and is correctly
treated as critical error, removed unneeded checks of NULL uri outside
of gst_uri_is_valid function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/816>
There is currently no way for users to receive incoming events from
appsink while keeping them properly serialized with the buffers flow.
This can be especially useful when application is injecting custom
downstream events into the pipeline and needs to know when they reached
appsink.
Solving this by adding a new signal notifying about new incoming events
and a set of action signals and method to pull those events.
The API is actually pulling the samples and events all together as they
are actually fetched from the same queue.
Having a specific API to pull only events would have the side effect of
discarding samples (and pulling samples would discard events) making
this API not convenient for users.
Partially fix#247
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1046>
The problem is that EGLNativeWindowSurface and wl_egl_surface are the
same object underneath, so we must recreate both together. As an
optimization, the EGLNativeWindowSurface wrapper is only re-created
if the window_handle changed.
On Mesa, this would cause crash, which will be fixed by:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11979
And will lead to proper errors in the future or on other GL stack. This
issue was encounter using a permanent GstGLDisplay after cycling one of
multiple independent pipelines through NULL state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1230>
120 bytes in 5 blocks are definitely lost in loss record 7,615 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9CA8E: cleanup_cb (gstptpclock.c:1930)
by 0x589AD20: g_timeout_dispatch (gmain.c:4889)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
576 bytes in 24 blocks are definitely lost in loss record 8,782 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9EFA0: handle_announce_message (gstptpclock.c:934)
by 0x5B9EFA0: handle_ptp_message (gstptpclock.c:1765)
by 0x5B9EFA0: have_stdin_data_cb (gstptpclock.c:1851)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
by 0x5DA4298: start_thread (pthread_create.c:481)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/852>
Currently the decoder selection is very naive: The type with the highest
rank that matches the current caps is used. This works well for software
decoders. The exact supported caps are always known and the static caps are
defined accordingly.
With hardware decoders, e.g. vaapi, the situation is different. The decoder
may reject the caps later during a caps query. At that point, a new decoder
is created. However, the same type is chosen an after several tries,
decodebin fails.
To avoid this, do the caps query while adding the decoder and try again
with other decoder types if the query fails:
1. create the decoder from the next matching type
2. add and link the decoder
3. change the decoder state to READY
4. do the caps query
if it fails then remove the decoder again and go back to 1.
5. expose the source pad
6. sync the decoder state with the parent.
This way, the decoder is already part of the pipeline when the state change
to READY happens. So context handling should work as before.
Exposing the source pad after the query was successful is important:
Otherwise the thread from the decoder source pad may block in a blocked pad
downstream in the playsink waiting for other pads to be ready.
The thread now blocks trying to set the state back to NULL while holding
the SELECTION_LOCK. Other streams may block on the SELECTION_LOCK and the
playsink never unblocks the pad. The result is a deadlock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1201>
When the window is called, we properly destroy all surfaces, which effectively
will unmap that surface and should make it disapear on screen, but we also
destroy the wl_source, a GSource that is resposibble of dispatching and executing
messages to/from the Wayland server.
As a side effect, the server never gets the message and the surfaces are
"leaked" on the server. We fix this using wl_display_flush() before destroying
the wl_source.
Fixes#815
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1226>
Previously one of the branches did not check for the property value. To
avoid this in the future, check inside the QoS calculation function
instead.
As a side effect this now always prints the debug messages into the logs
when samples are dropped, which is useful information even without the
QoS messages.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
If a buffer is dropped during resyncing on a discont because either its
end offset is already before the current output offset of the
aggregator or because it fully overlaps with the part of the current
output buffer that was already filled, then don't just assume that the
next buffer is going to start at exactly the expected offset. It might
still require some more dropping of samples.
This caused the input to be mixed with an offset to its actual position
in the output stream, causing additional latency and wrong
synchronization between the different input streams.
Instead consider each buffer after a discont as a discont until the
aggregator actually resynced and starts mixing samples from the input
again.
Also update the start output offset of a new input buffer if samples
have to be dropped at the beginning. Otherwise it might be mixed too
early into the output and overwrite part of the output buffer that
already took samples from this input into account.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/912
which is a regression introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1180/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
A video decoder can now receive subframes and start decoding
instead of waiting for the full frame to be complete.
Subframe support will reduce latency as described in the
video encoder base class.
A unit test illustrating this API is available in
tests/check/libs/videodecoder.c.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/454>
