This introduces a more human friendly syntax to specify nested
structures It does so by using 2 different markers for opening and
closing them instead of abusing quotes which lead to requiring an insane
amount of escaping to match nesting levels.
The brackets (`[` and `]`) have been chosen as they avoid complex
constructions with curly brackets (or lower/higher than signs) where you
could have structures embedded inside arrays (which also use curly
brackets), ie. `s, array=(structure){{struct}}` should be parsed as an
array of structures, but the cast seems to imply something different. We
do not have this issue with brackets as they are currently used for
ranges, which can only be casted to numeric types.
This commit does not make use of that new syntax for serialization as
that would break backward compatibility, so it is basically a 'sugar'
syntax for humans. A notice has been explicitly made in the
documentation to let the user know about it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/532>
The various wait implementation have a latency ranging from 50 to 500+
microseconds. While this is not a major issue when dealing with a low number of
waits per second (for ex: video), it does introduce a non-negligeable jitter for
synchronization of higher packet rate systems.
The `clock_nanosleep` syscall does offer a lower-latency waiting system but is
unfortunately blocking, so we don't want to use it in all scenarios nor for too
long.
This patch makes GstSystemClock use clock_nanosleep (if available) as such:
* Any wait below 500us uses it
* Any wait below 2ms will first use the regular waiting system and then
clock_nanosleep
# modified: gst/gstsystemclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/688>
While the default implementation will spawn a thread per new
pushed task, this new implementation instead spawns a maximum
number of threads, then queues new tasks on existing threads.
The thread that the new task will be queued on is picked in
a pretty naive fashion, by simply popping the first thread
from a queue and pushing it back to the tail, but this is
an implementation detail and can always be sophisticated
in the future if the need arises.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/692>
While the default implementation passes NULL around as the
task handle, other implementations can only provide a safe
API by having that handle map to a refcounted opaque type.
While what's passed around is a gpointer, a valid transfer
type annotation has informative value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/692>
When compiling for 32bit architectures with 64bit time_t e.g. riscv32,
the static assert that the GstClockEntryImpl smaller or
equal to the struct _GstClockEntryImpl triggered.
(they were 12bytes off).
To fix this, the padding is increased by 8 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/694>
When parsing interlaced video streams, ignoring incoming DTS could
cause the parser to end up with PTS < DTS output buffers, for example
when increasing next_dts using the duration of the last pushed
buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/681>
If a device provider fails to start (for instance the pulseaudio provider unable
to connect to the PulseAudio daemon) then the monitor should not keep track of
it in its `started` providers list. Otherwise a false positive critical warning
would be raised.
This patch also switches the started_count type from bool to int, for
consistency. This is a counter, after all.
API: gst_device_provider_is_started
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/679>
While we can fixe the upstream latency using the min-upstream-latency, we
are now forced to use queues (hence more thread) in order to store the pending
data whenever we have an upstream source that has lower latency.
This fixes the issue by allowing to buffer the fixed upstream latency. This is
particularly handy on single core systems were having too many threads can
cause serious performance issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/677>
In order to support the symbol g_enum_to_string in various
project using GStreamer ( gst-validate etc.), the glib minimum
version should be 2.56.0.
Remove compat code as glib requirement
is now > 2.56
Version used by Ubuntu 18.04 LTS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/199>
Typing hints can only be passed to gst_value_deserialize()
through the type of the passed-in value. This means deserialization
can only target the desired type for the top-level elements,
making it for example impossible to deserialize an array of
flags to the expected type.
This commit exposes a new function, gst_value_deserialize_full(),
that takes an optional pspec as the extra parameter, and updates
the deserialization code to pass around that pspec, or the
element_spec when recursively parsing the elements of a list-type
value.
This allows for example passing arrays of flags through the
command line or gst_util_set_object_arg, eg:
foo="<bar,bar+baz>"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/629>
... and update meson file so that enable it only using required headers.
"dependency(...)" is unlikely successful for Windows SDK libraries
since it doesn't ship pkg-config file. So it needs to be changed
to "find_library()" to link corresponding .lib file. That would
result to most MSVC build system will link dbghelp.dll. However,
one drawback of the change is that gstreamer-1.0.dll will mandate
dbghelp.dll although it should be optional. So g_module_open() way
can be the most safe way in this case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/626>
