GitLab

Otherwise, last line can be lost.

https://bugzilla.gnome.org/show_bug.cgi?id=797350

If a segment has stop == -1, then gst_segment_to_running_time()
would refuse to calculate a running time for negative rates,
but gst_segment_do_seek() allows this scenario and uses a
valid duration for calculations.

Make the 2 functions consistent by using any configured duration
to calculate a running time too in that case.

https://bugzilla.gnome.org/show_bug.cgi?id=796559

https://bugzilla.gnome.org/show_bug.cgi?id=797344

It's not a warning if an URI doesn't have an extension, and it's also
not mandatory that sources have an URI or even answer the URI query.

Jordan Petridіs authored Oct 16, 2018 and Sebastian Dröge committed Oct 23, 2018

GST_TIME_FORMAT, GST_TIME_ARGS, GST_STIME_FORMAT, GST_STIME_ARGS
GST_PTR_FORMAT, GST_SEGMENT_FORMAT, GST_FOURCC_FORMAT and
GST_FOURCC_ARGS are format specifiers.
They can't be used outside of C and should be generated in the gir.

https://bugzilla.gnome.org/show_bug.cgi?id=797320

Jordan Petridіs authored Oct 16, 2018 and Sebastian Dröge committed Oct 23, 2018

GST_ERROR_SYSTEM can't really be used outside of C and should
be skipped.

https://bugzilla.gnome.org/show_bug.cgi?id=797320

Edward Hervey authored Oct 22, 2018 and Edward Hervey committed Oct 22, 2018

Since we use full signed running times, we no longer need to clamp
the buffer time.

This avoids having the position of single queues not advancing for
buffers that are out of segment and never waking up non-linked
streams (resulting in an apparent "deadlock").

Edward Hervey authored Oct 22, 2018 and Edward Hervey committed Oct 22, 2018

If we ever get a GST_FLOW_EOS from downstream, we might retry
pushing new data. But if pushing that data doesn't return a
GstFlowReturn (such as pushing events), we would end up returning
the previous GstFlowReturn (i.e. EOS).

Not properly resetting it would cause cases where queue2 would
stop pushing on the first GstEvent stored (even if there is more
data contained within).

Use the test clock instead of using a real one to make it
easier to run in valgrind.

https://bugzilla.gnome.org/show_bug.cgi?id=797291

Using the MEDIA_ classifier prefix was inappropriate. It is sufficient to
specify the additional klass name that element can set in their metadata.

(follow-up of commit ca4b61c5)

https://bugzilla.gnome.org/show_bug.cgi?id=796921

The Harware factory type classifier allows elements (decoders and encoders,
mostly) to advertize they rely on hardware devices to perform encoding or
decoding operations. This classifier can be used by applications to filter and
select only the elements that use hardware devices, for instance to ensure
zero-copy support is enabled for a specific pipeline.

https://bugzilla.gnome.org/show_bug.cgi?id=796921

Aleix Conchillo Flaqué authored Oct 10, 2018 and Tim-Philipp Müller committed Oct 12, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=797269

Previously, with opportunistic sync we'd track a master
clock as soon as we see a SYNC message, and hence sync up
faster, but then we'd announce we're synched before seeing
the ANNOUNCE, leaving the clock details like grandmaster-clock
empty.

A better way is to start tracking the clock opportunistically,
but not announce we're synched until we've also seen the ANNOUNCE.

Log message arrival times. Fix a typo in one debug string

The follow-up and delay-resp messages carry precise
timestamps for the arrival at the clock master, but
the local return time is unimportant, so we should be very
lenient in accepting them late. Some PTP masters don't
prioritise sending those packets, and we reject all the
responses and never sync - or take forever to do so.

Increase the tolerance to 20x the mean path delay.

Also fix a typo in one debug output that would print
the absolute time of the delay-resp message, not the offset
from the delay-req that it's actually being compared against.

Add some debugging to be able to tell what is happening
inside the PTP clock protocol handling.

https://github.com/mesonbuild/meson/pull/4169

https://bugzilla.gnome.org/show_bug.cgi?id=797213

Setting it to "unspecified-system-id".

Yacine Bandou authored Oct 01, 2018 and Thibault Saunier committed Oct 03, 2018

In some cases the system protection ID is not present in the contents
or in their metadata.
This define is used to set the value of the "system_id" field in GstProtectionEvent,
with this value, the application will use an external information to choose which
protection system to use.

Example: The matroskademux uses this value in the case of encrypted WebM,
the application will choose the appropriate protection system based on the information
received through EME API.

https://bugzilla.gnome.org/show_bug.cgi?id=797231

gst_queue_array_clear will clear the GstQueueArray,
gst_queue_array_set_clear_func will set a clear function for each
element to be called on _clear and on _free.

https://bugzilla.gnome.org/show_bug.cgi?id=797218

This is exposed as a solution to the use case of plugging in
sources with a higher latency after the aggregator has started
playing with an initial set of sources, allowing to avoid resyncing.

https://bugzilla.gnome.org/show_bug.cgi?id=797213

The documentation incorrectly used to state that the pads were
not automatically activated when added, whereas we actually do
that when appropriate.

Callers of gst_element_add_pad must not hold the object lock,
which implies that they cannot perform the same checks as
add_pad in a non-racy manner.

This updates the documentation, and removes the g_warning
that was output before performing automatic activation.

https://bugzilla.gnome.org/show_bug.cgi?id=797181

Otherwise we try to build a shared lib when we build the rest
of GStreamer statically, which won't work because we pass
-DGST_STATIC_COMPILATION when building statically, which means
we won't dllimport public symbols from our libs which means
that on Windows the unit tests will fail to link to libgstcheck.

https://bugzilla.gnome.org/show_bug.cgi?id=797185

Can't mix/match imports and exports from the same library
here, so just include all .c files needed instead and don't
link to gstnet at all then.

https://bugzilla.gnome.org/show_bug.cgi?id=797185

Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.

The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.

We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.

The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h

Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.

This commit depends on a common submodule commit that makes ...

For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.

This fixes linker warnings on Windows when building with MSVC.

The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.

What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.

https://bugzilla.gnome.org/show_bug.cgi?id=797185

This is for use by the various GST_*_API decorators and
will be what they get defined to when a library API is being
used by external users of that library (not the library itself
whilst it's being compiled).

In most cases it will simply map to a plain 'extern' but on
Windows with MSVC it will need to map to __declspec(dllimport).
For functions this is not strictly needed, but for exported
variables it is.

https://bugzilla.gnome.org/show_bug.cgi?id=797185

Seungha Yang authored Sep 21, 2018 and Tim-Philipp Müller committed Sep 21, 2018

Fix build on some non-US locale Windows systems

Error:
  gstreamer/gst/gstdebugutils.c(194): error C2001

https://bugzilla.gnome.org/show_bug.cgi?id=797186

https://bugzilla.gnome.org/show_bug.cgi?id=797165

And fix up bogus libs/ prefix for controller lib includes.

https://bugzilla.gnome.org/show_bug.cgi?id=797165

Linus Svensson authored Sep 18, 2018 and Tim-Philipp Müller committed Sep 19, 2018

Change to always include gst/libs/base.h in order to also
include base-prelude.h, but also because it's the right
thing for people to include anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=797165

We want this enabled by default, also in releases, but people
may want to disable this for performance-critical workloads or
on embedded devices.