clock: Don't allow setting an unsynced clock as master

clock: Don't try to slave unsynced clocks

They will return useless values from get_time().

ntp: The clock inherits from GstNetClientClock, not just GstSystemClock

netclientclock: Destroy a cached clock 60 seconds after its last use

There's not much lost by having the clock idle around a bit longer but it will
potentially allow anybody wanting to use the same clock server again to sync
much faster.

netclientclock: Only ever run one clock against a specific server

If multiple net/NTP clocks are created for the same server, reuse the same
internal clock for all of them. This makes sure that we don't flood the server
with too many requests and also possibly allows faster synchronization if
there already was an earlier synchronized clock when creating a new one.

nettimeprovider: Use GInitable instead of having a new() function that can return NULL

Bindings don't like that much and as we're using GIO here anyway we can as
well use GInitable for possibly failing initialization.

nettimeprovider: Mark address, port and clock properties CONSTRUCT_ONLY

They can't sensibly be changed after construction.

parse_launch: make nicer log messages

Add two macros to build nicer element/pad name strings. The macros avoid
printing "(NULL)" and print the element type in addition to the name.

parse-launch: warn when still waiting to plug sub-pipelines after no-more-pads

The parse-launch API automagically handles dynamic pads and performs delayed
linking as needed, without any feedback about whether the linking succeeded or
not however. If a delayed dynamic link can't be completed for whatever reason,
parse-launch will simply wait in case a suitable pad appears later. This may
never happen though, in which case the pipeline may just hang forever.

Try to improve this by connecting to the "no-more-pads" signal of any element
with dynamic pads and posting a warning message for the related outstanding
dynamic links when "no-more-pads" is emitted.

Fixes #760003

docs: fix some warnings and add some since markers

tracing: add some pointers about memory tracing

grammar.y: remove trailing whitespace

tests: value: test buffer serialisation/deserialisation more thoroughly

Tests data/strings as well, not just that we received
something non-NULL back.

gst: fix typo in comment

netclientclock: Implement resolval of hostnames

Just allowing IPs here is not ideal and implementing DNS resolval is easy.

ptpclock: Add read-only properties to get the master and grandmaster clock ids

caps: Add (transfer full) annotation to simplify() and subtract() return value

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

caps: add 'transfer full' annotation to caps returned by interserction functions

To make clear caller is responsible to unref them.

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

net: Add NTP and PTP clock types to the docs

This gives us the property documentation for example.

check: don't memcmp twice

Simply call fail() in the condition after the first memcmp.

Back to development

Release 1.7.1

Update .po files

po: Update translations

configure: Make -Bsymbolic check work with clang.

Update the -Bsymbolic check with the version glib has. This version
works with clang.

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

docs: update to git

core: Add g_autoptr() support to all types

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

tee: Check if parsing the name template with sscanf() was successful

If not, go back to the automatic pad numbering.

CID 1195129

queue/multiqueue: Don't special-case CAPS events in the event handlers

For CAPS events we will never ever have a FALSE return value here, so just
remove the dead code instead of causing future confusion.

Revert "queue: Illegal memory access of sink event"

This reverts commit 78614c505a2a761cb4dcb7f4e5f3e9f97c9a8e88.

The code it was fixing does not have any effect anyway and will be removed in
the next commit.

queue: Illegal memory access of sink event

Once event is pushed to pad, then queue should not access the event.
This is leading to invalid read valgrind errors

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

element: Unref event if GstElement::send_event() is not implemented

Otherwise we'll take ownership of the event only if it's implemented, and
leak the event in all other situations.

manual: Fix dynamic pipeline example

Use GST_PAD_PROBE_PASS to pass through all events other than EOS instead of
blocking on the first non-EOS event forever. Also fix a typo in a comment in
that function.

Thanks to David Jaggard for reporting this on the mailing list.

docs:  typo in the location of make_element tool

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

downloadbuffer: drop unneeded macros for G_OS_WIN32

fdsrc: drop unneeded macros for G_OS_WIN32

fdsrc: enable large file support in Android

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

fdsink: enable large file support in Android

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

queue2: fix some typos

queue2: enable large file support on Android

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

downloadbuffer: fix some typos

downloadbuffer: enable large file support on Android

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

sparsefile: drop bogus reference to file descriptor

+fix typo on return value comment

sparsefile: enable large file support on Android

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

element: unref message in _post_message when there is no implementation

'gst_element_post_message' takes the ownership of the message, so it
shall unref it when there is no post_message implementation. Otherwise
message is leaked.

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

element: Don't hold state lock all the time while sending an event

This lock seems to exist only to prevent elements from changing states while
events are being processed. However events are going to be processed
nonetheless in those elements if sent directly via pads, so protection must
already be implemented inside the elements for event handling if it is needed.

As such having the lock here is not very useful and is actually causing
various deadlocks in different situations as described in
https://bugzilla.gnome.org/show_bug.cgi?id=744040

filesrc: enable large file support in Android

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

filesink: enable large file support on Android

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

filesink: indentation fixes

multiqueue: Don't use random segment.position from upstream

segment.position is meant for internal usage only, but the various
GST_EVENT_SEGMENT creationg/parsing functions won't clear that field.

Use the appropriate segment boundary as an initial value instead

bin: Post a LATENCY message with async-handling=TRUE if the PLAYING state is reached

Otherwise each bin might have a different latency in the end, causing
synchronization problems.

The bin will still first handle latency internally as before, but gives the
overall pipeline the opportunity to update the latency of the whole pipeline
afterwards.

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

baseparse: post tag list when avg bitrate changes at least 2%

Watching videos with variant bitrate is common to have delta
more than 10 kbps, resulting in tag list spam.

Instead of relying on fixed 10 kpbs delta, it is better to
calculale the difference in percentage and update tag list
only when bitrate changes more than 2%.

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

Automatic update of common submodule

From b319909 to 86e4663

element: Check for an activated pad before adding, not a non-flushing one

The pad could be activated but flushing because of a FLUSH_START event. That's
not what we're looking for here, we want to check for activated pads.

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

tests: funnel: remove state change from stress tests

Changing states up and down while buffers are being pushed is not
a valid use case. If a pad is deactivated and reactivated during
a buffer push it is racy with the check of pushed sticky events
and the actual chainfunction call. As it might call the chain
without noticing the peer pad lost its previous sticky events.

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

gst-launch: Fix process return value on error

In case of a run-time error message, the process return value was left
unset. This would lead to error not being caught at shell level.

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

Revert "tools: gst-launch: return non-0 exit code on async error"

This reverts commit 2ee4cba2485d7f1646d48e4559426aed4ba99c85.

tools: gst-launch: return non-0 exit code on async error

When an error happens in playing state, still return a
non-0 exit code.

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

helpers: really fix install race

My previous fix for #758029 wasn't quite right and simply made the race rarer.
Some of the files are installed by install-exec and others by install-exec, so
the hooks need to be split too.

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

query: fix docs

The allocation query has parameters with the meta API, not flags.

Drop usage of deprecated g-ir-scanner --strip-prefix flag

multiqueue: Fix set/get property

Blame it on the rebasing :)

pad: Implement GstPadEventFullFunction

API: GstPadEventFullFunction

Returns a GstFlowReturn, allows asynchronous elements to properly
propagate flow returns

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

multiqueue: Use signed clock values for running time calculation

This improves the accuracy of queue levels and when to push buffers
for buffers falling outside of the segment

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

multiqueue: Add an extra cache time for unlinked streams

When synchronizing the output by time, there are some use-cases (like
allowing gapless playback downstream) where we want the unlinked streams
to stay slightly behind the linked streams.

The "unlinked-cache-time" property allows the user to specify by how
much time the unlinked streams should wait before pushing again.

multiqueue: Optimize multiqueue sizes based on interleave

Multiqueue should only be used to cope with:
* decoupling upstream and dowstream threading (i.e. having separate threads
  for elementary streams).
* Ensuring individual queues have enough space to cope with upstream interleave
  (distance in stream time between co-located samples). This is to guarantee
  that we have enough room in each individual queues to provide new data in
  each, without being blocked.
* Limit the queue sizes to that interleave distance (and an extra minimal
  buffering size). This is to ensure we don't consume too much memory.

Based on that, multiqueue now continuously calculates the input interleave
(per incoming streaming thread). Based on that, it calculates a target
interleave (currently 1.5 x real_interleave + 250ms padding).

If the target interleave is greater than the current max_size.time, it will
update it accordingly (to allow enough margin to not block).
If the target interleave goes down by more than 50%, we re-adjust it once
we know we have gone past a safe distance (2 x current max_size.time).

This mode can only be used for incoming streams that are guaranteed to be
properly timestamped.

Furthermore, we ignore sparse streams when calculating interleave and maximum
size of queues.

For the simplest of use-cases (single stream), multiqueue acts as a single
queue with a time limit of 250ms.
If there are multiple inputs, but each come from a different streaming thread,
the maximum time limit will also end up being 250ms.

On regular files (more than one input stream from the same upstream streaming
thread), it can reduce the total memory used as much as 10x, ending up with
max_size.time around 500ms.

Due to the adaptive nature, it can also cope with changing interleave (which
can happen commonly on some files at startup/pre-roll time)

multiqueue: use new stream-start event sparse flag to avoid overreading subtitles

This will mean a much lower delay before a subtitles track changes take
effect. Also avoids excessive memory usage in many cases.

This will also consider sparse streams as (individually) never full, so
as to avoid blocking all playback due to one sparse stream.

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

multiqueue: Fix high_time computation

* Avoid the computation completely if we know we don't need it (not in
  sync time mode)
* Make sure we don't override highest time with GST_CLOCK_TIME_NONE on
  unlinked pads
* Ensure the high_time gets properly updated if all pads are not linked
* Fix the comparision in the loop whether the target high time is the same
  as the current time
* Split wake_up_next_non_linked method to avoid useless calculation

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

queue2: Don't report 0% unless empty

When preparing a buffering message, don't report 0% if there
is any bytes left in the queue at all. We still have something
to push, so don't tell the app to start buffering - maybe
we'll get more data before actually running dry.

gstclock: Fix GST_STIME_ARGS

It wasn't properly handling GST_CLOCK_STIME_NONE and always use the
sign marker (+/-) to make it easier to identify signed values in
logs

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

controlsource: Annotate get_value[_array] as (method)

As the names clash with gst_object_get_value[_array]

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

plugin: Add prefix support to dependencies

This adds a new flags, GST_PLUGIN_DEPENDENCY_FLAG_FILE_NAME_IS_PREFIX,
which allow using the names as prefix for plugin depencies.

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

plugin: Allow device nodes as dependency

This is useful for feature that are produced after probing a specific
node. You want to reload this plugin if the specific node(s) have been
removed, added, or reloaded.

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

plugin: Don't do lossy shift on hash

In plugin is responsible for calculating a hash of the dependencies
in order to determine if the cache should be invalidated or not.
Currently, the hash combining method removes a bit of the original
have before combining with an addition. As we use 32bits for our hash
and shift 1 bit for each file and directory, that resulting hash only
account for the last 32 files. And is more affected by the last file.

Rotating technique (shifting, and adding back the ending bit), can be
use to make the addition non-commutative. In a way that different order
gives different hashes. In this case, I don't preserve this behaviour
because the order in which the files are provided by the OS is
irrelevant.

In most cases, the XOR operation is used to combine hashes. In this
code we use the addition. I decided to preserve the addition because
we make use of non-random hash ((guint) -1) in the algorithm for
matching files that are not really part of the hash (symlinks, special
files). Doing successive XOR on this value, will simply switch from
full ones, to full zero. The XOR used with whitelist has been preserved
as it's based on a fairly randomized hash (g_str_hash).

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

info: fix compiler warning with -Wpedantic and gcc 5

Gstreamer compiled with gcc 5.2 and -Wpedantic produces the
following warning:

'ISO C does not support '__FUNCTION__' predefined identifier [-Wpedantic]
  const char *s = __FUNCTION__;'

Since gcc 5 enables C99 by default, use __func__ if it's available
instead of the non-standard __FUNCTION__ (as suggested in [2]).

[1]: https://gcc.gnu.org/gcc-5/changes.html
[2]: https://gcc.gnu.org/gcc-5/porting_to.html

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

controller: fix annotation to make g-ir-scanner happy

gstinterpolationcontrolsource.h:59: Warning: GstController: missing ":" at column 51:
 * @GST_INTERPOLATION_MODE_CUBIC_MONO: (Since 1.8) monotonic cubic interpolation, will not
gstinterpolationcontrolsource.h:59: Warning: GstController: unknown annotation: since

tags: add GST_TAG_PRIVATE_DATA

Can be used to represent private data that may be
contained in tags, such as ID3v2 PRIV frames.

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

Revert "baseparse: do not overwrite header buffer timestamps"

This reverts commit 2c475a035543efc0202ecdc52070295a421ed4b4.

This causes issues with h264parse. It breaks timestamps as
there are headers in the middle of the stream and this patch
makes the timestamps for those differ from the ones that
are adjusted, creating a discontinuity and leading to sync
issues.

Revert "baseparse: simplify code a bit"

This reverts commit 3984f7159a72c2eebe01905ee53716e3b2abcb30.

queue2: don't print criticals when receiving custom events in ring buffer mode

Downgrade from g_warning to GST_WARNING log message.

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

ptp-helper: Disable multicast loopback

We're not really interested in our own packets and ignore them anyway.

debugutils: Fix string memory leak

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

baseparse: simplify code a bit

Avoid repeated checks for testing if a buffer is a header

collectpads: handle buffer with dts-only when mapping to running time

Otherwise the buffer was left with the original values and later would
be compared with other buffers that were converted to runninn time,
leading to bad interleaving of multiple streams.

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

baseparse: do not overwrite header buffer timestamps

baseparse tries to preserve timestamps from upstream if
it is running on a time segment and write that to
output buffers. It assumes the first DTS is going to be
segment.start and sets that to the first buffers. In case
the buffer is a header buffer, it had no timestamps and
will have only the DTS set due to this mechanism.

This patch prevents this by skipping this behavior for
header buffers.

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

identity: add drop-buffer-flags property

New property drop-buffer-flags that will discard buffers that have the
given flags set.

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

helpers: fix install race

The install hook needs to be a install-data-hook not an install-exec-hook as the
helpers are installed into helperdir which is considered data (only path
variables with "exec" in are considered executables).

The explicit dependency on install-helpersPROGRAMS was an attempt at solving
this, but this causes occasional races where install-helpersPROGRAMS can run
twice in parallel (once via install-all, once via the hook's dependency).

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

systemclock: Add test for gst_clock_get_resolution

In a series of time measurements, the diff between now and previous
timestamps is either 0 or at least as long as get_resolution returned.

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

systemclock: Use mach_time on Apple platforms

On iOS/OSX g_get_current_time was used by default. However, mach_time is
the preferred high-resolution monotonic clock to be used on Apple
platforms.

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

tracers: log: add missing hooks

Log all possible hooks

tracer: add element-change-state-pre/post hook

Helps catching when a state change is starting and ending.

It is also possible to track the end of state changes by checking the
async-done or state-change messages.
This is particularly important for elements that do async state changes.

pad: test for checking the order of the probe calls

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

context: fix some copy and paste leftover in docs

context: add some more documentation

Add a short paragraph on what means for a context to be persistent

utils: use 'static inline' instead of 'inline static' for gtk-doc

gtk-doc doesn't seem to recognise the former variant.

docs: remove dummy function declarations with G_INLINE_FUNCTION for gtk-doc

gtk-doc can handle static inline functions just fine these days,
there's no need for this stuff any more.

queue2: Add the avg-in-rate property.

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

queue2: add overrun signal

Notifies that the queue2 is full, same as queue does

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

pad: tests for accept-caps handling with proxy pads

Adds 3 new tests for testing accept-caps behavior with
proxy-caps pads.

1) A scenario where there is no proxy. The caps should be compared to the
template caps of the pad

2) A scenario where there is a compatible pad. The caps should be compared
to the proxied pad caps (and also with the template)

3) A scenario where there is an incompatible proxy pad. No caps should be
possible at all.

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

pad: check template caps for proxy pads in accept-caps

Validate that the proxy pad indeed accepts the caps by also
comparing with the pad template caps, otherwise when the pad
had no internally linked pads it would always return true.

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