GitLab

gst_clock_wait_for_sync(), gst_clock_is_synced() and gst_clock_set_synced()
plus a signal to asynchronously wait for the clock to be synced.

This can be used by clocks to signal that they need initial synchronization
before they can report any time, and that this synchronization can also get
completely lost at some point. Network clocks, like the GStreamer
netclientclock, NTP or PTP clocks are examples for clocks where this is useful
to have as they can't report any time at all before they're synced.

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

There are gstmemory's available that operate in two memory domains
and need to ensure consistent access between these domains.

Imagine a scenario where e.g. the GLMemory is mapped twice in both
the GPU and the CPU domain.  On unmap or a subsequent map, it would
like to ensure that the most recent data is available in the memory
domain requested.  Either by flushing the writes and/or initiating a
DMA transfer.  Without knowing which domain is being unmapped, the
memory does not know where the most recent data is to transfer to
the other memory domain.

Note: this still does not allow downgrading a memory map.

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

Now that locking exclusively dows not always succeed, we need to signal
the failure case from gst_memory_init.

Rather than introducing an API or funcionality change to gst_memory_init,
workaround by checking exclusivity in the calling code.

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

Attempt to return a copy of the memory instead.

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

gst_memory_lock (mem, WRITE | EXCLUSIVE);
gst_memory_lock (mem, WRITE | EXCLUSIVE);

Succeeds when the part-miniobject.txt design doc suggests that this should fail:

  "A gst_mini_object_lock() can fail when a WRITE lock is requested and
  the exclusive counter is > 1. Indeed a GstMiniObject object with an
  exclusive counter 1 is locked EXCLUSIVELY by at least 2 objects and is
  therefore not writable."

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

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

to avoid the deadlock in playbin2,
send msg after release the download buffer lock.

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

We've already done this earlier in the function,
and nothing has changed since we first read it.

DllMain should not be relied on for anything except storing the DLL handle.
It should also not be defined for static builds, but doing so is not
straightforward and is mostly harmless, so let's just add a comment about that
for now.

This obsolete folder hasn't been touched since 2001 and has no purpose. It
confuses new developers.

gst_value_take_buffer() and gst_value_take_sample() both resolve to
g_value_take_boxed().  Use the method with the correct name if we
ever change that.

GstFlagSet is a new type designed for negotiating sets
of boolean capabilities flags, consisting of a 32-bit
flags bitfield and 32-bit mask field. The mask field
indicates which of the flags bits an element needs to have
as specific values, and which it doesn't care about.

This allows efficient negotiation of arrays of boolean
capabilities.

The standard serialisation format is FLAGS:MASK, with
flags and mask fields expressed in hexadecimal, however
GstFlagSet has a gst_register_flagset() function, which
associates a new GstFlagSet derived type with an existing
GFlags gtype. When serializing a GstFlagSet with an
associated set of GFlags, it also serializes a human-readable
form of the flags for easier debugging.

It is possible to parse a GFlags style serialisation of a
flagset, without the hex portion on the front. ie,
+flag1/flag2/flag3+flag4, to indicate that
flag1 & flag4 must be set, and flag2/flag3 must be unset,
and any other flags are don't-care.

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

Just create the cancellable fd once and keep it around instead
of creating/closing it for every single packet. Since we spend
most time waiting for packets, an fd is alloced and in use pretty
much all the time anyway.

This reverts commit 460a7bf6.

This should be fixed by the gtk-doc 1.23 release.

<para> cannot contain <refsect2>:
http://www.docbook.org/tdg/en/html/para.html
http://www.docbook.org/tdg/en/html/refsect2.html

The error path unrefs file->file so make sure we only go there when
there is a non-NULL file->file.

With gtkdoc 1.22, the XML generator fails when a itemizedlist is
followed by a refsect2. Workaround the issue by wrapping the refsect2
into para.

Previous patch was assuming that if the returned iter was the last iter
the GSequence was empty, which is obviously wrong.

We were segfaulting because g_sequence_search was returning the iter_end,
and that iterator does not contain anything and thus should not be used
directly

We're enterprise now folks.

They're really useful compared to other LOG stuff in there, so
there is value is including them and not the rest.

The old gst_object_has_ancestor will call the new code. This establishes the
symetry with the new gst_object_has_as_parent.

API: gst_object_has_as_ancestor()

This avoid confusion with a potential punction that check if a gstobject has-a
parent.

API: gst_object_has_as_parent()

In basesink functions gst_base_sink_chain_unlocked(), below code is used to
checking if buffer is late before doing prepare call to save some effort:
    if (syncable && do_sync)
      late =
          gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
          GST_CLOCK_EARLY, 0, FALSE);

    if (G_UNLIKELY (late))
      goto dropped;

But this code has problem, it should calculate jitter based on current media
clock, rather than just passing 0. I found it will drop all the frames when
rewind in slow speed, such as -2X.

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

Update example to use gst-launch-1.0 and fix a paragraph.

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

And some small example pipeline fix-ups.