gst: Fix spelling error

Thank to Adrian Owen for reporting this error.

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

typefindelement: do not leak sticky events in flush_stop

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

info: avoid global variable for log_file

Use user_data to pass the log_file handle to the logger-function.

If one wants to change the log target (e.g. GST_DEBUG_FILE), simply call
gst_debug_remove_log_function() and re-add the handler with the new log-target
using gst_debug_add_log_function ().

event: add annotations to gst_event_parse_toc_select()

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

multiqueue: do not post messages holding the lock

It might cause deadlocks to post messages while holding the multiqueue
lock. To avoid this a new boolean flag is set whenever a new buffering percent
is found. The message is posted after the lock can be released.

To make sure the buffering messages are posted in the right order, messages
are posted holding another lock. This prevents 2 threads trying to post
messages at the same time.

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

docs: fix typo

query: Add annotations to gst_query_add_allocation_pool()

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

basesrc: handle reference in set_allocation rather than in prepare_allocation

Otherwise we can forget to unref objects in error cases.

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

check: Use the name parameter of gst_check_setup_src_pad_by_name() and the sink variant

This was hardcoded to "sink" / "src" by accident in previous refactoring.

coreelements: mark properties with MUTABLE_PLAYING

check: Add a function to check destruction of objects

Add a method letting people to ensure that unreffing one object
leads to its destruction, and possibly the destruction of more object
(think destruction of a GstBin etc...).

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

tools: gst-inspect: don't list pad functions

Don't print all the different pad functions, it's just
confusing and no one has ever needed to know this for
anything ever anyway, it's just useless information.
Besides, we also label the default implementations as
'custom' implementations (the code that tries to
prevent that doesn't actually work it seems).

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

pad: Make sure the buffer to get/pull_range() has at least the requested size

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

check: Adding documentation to the gst_check_setup_sink_pad_by_name function

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

query: add annotations to gst_query_set_nth_allocation_pool()

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

valve: fix typo in description

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

baseparse: minor docs fix

devicemonitor: fix typo in sample code in docs

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

tests: add flush-stop on inactive pad test

Check that pushing flush-stop on an inactive pad does not clear the
flushing flag.

pad: don't accept flush-stop on inactive pads

Inactive pads should at all times have the flushing flag set. This means
that when we get a flush-stop on an inactive pad we must ignore it.

On sinkpads, make this more explicit. We used to not clear the flush
flag but remove the events and then return an error because the flushing
flag was set. Now just simply refuse the event without doing anything.

On srcpads, check that we are trying to push a flush-stop event and
refuse it. We would allow this and mark the srcpad as non-flushing
anymore.

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

output-selector: Send all events to active src pad and EOS to all src pads

Fixes tests/icles/output-selector-test

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

manual: fix typo in advanced-dataaccess.xml

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

buffer: do not touch memory tag flag when copying buffer flags

The tag memory flag will be set later if the memory is also copied. This
patch avoids buffers being freed needlessly in bufferpools.

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

bus: gst_bus_add_watch() can return 0 on error

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

baseparse: handle streamheaders by prepending them to the stream

Add a first_buffer boolean state flag to have baseparse do actions
before pushing data. This is used to check the caps for streamheader
buffers that are prepended to the stream, but only if the first buffer
isn't already marked with the _HEADER flag. In this case, it is assumed
that the _HEADER marked buffer is the same as the streamheader.

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

concat: Allow seeking on the currently playing stream

This is consistent with the stream time reporting.

pad: add g-i 'transfer full' annotations to chain and chain_list functions

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

pad: annotate GstPadEventFunction event with 'transfer full'

The callback is supposed to take ownership of the event so
best to be explicit about it.

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

tests: add test that triggers deadlock in state change of queue

When receiving FLASH_STOP in a state transition to READY, a queue
element can end up with an active task that will never end.

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

queue: fix race when flush-stop event comes in whilst shutting down

Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.

When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.

Spotted and debugged by Linus Svensson <linux.svensson@axis.com>

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

bytereader: add gst_byte_reader_peek_sub_reader() and _get_sub_reader()

Adds API to get or peek a sub-reader of a certain size from
a given byte reader. This is useful when parsing nested chunks,
one can easily get a byte reader for a sub-chunk and make
sure one never reads beyond the sub-chunk boundary.

API: gst_byte_reader_peek_sub_reader()
API: gst_byte_reader_get_sub_reader()

docs: make explicit that the caps passed to gst_base_src_set_caps() are 'tranfer none'

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

inputselector: always proxy caps query

Otherwise it would only be proxied for the active pad which can lead
upstream to use an incompatible caps for the downstream element.

Even if a reconfigure event is sent upstream when the pad is activated, this
will save the caps reconfiguration if it is already using an acceptable caps.

base: and fix build with new g-i again

base: remove g-i annotation that makes older g-ir-scanner crash

Just remove one skip annotation that causes this:

  ** (g-ir-compiler:12458): ERROR **: Caught NULL node, parent=empty

with older g-i versions such as 1.32.1.

bus: destroy signal watch from the context it was mapped to

Don't rely on g_source_remove() because it operates on the main
context. If a signal watch was added to a new thread-default context
g_source_remove() would have no effect. So simply use
g_source_destroy() to avoid this problem.

Additionally the source_id was removed from GstBusPrivate because it
was redundant with the signal watch GSource also stored in that
structure.

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

multiqueue: Not post BUFFERING message if one of the singlequeue doesn't need it

Imagine the following 'pipeline'

                --------------
            p1/| 'fullqueue'  |--- 'laggy' downstream
  ---------  / |              |
-| demuxer |   | multiqueue   |
  ---------  \ |              |
            p2\| 'emptyqueue' |--- 'fast' downstream
                --------------

In the case downstream of one single queue (fullqueue) has (a lot of) latency
(for example for reverse playback with video), we can end up having the other
SingleQueue (emptyqueue) emptied, before that fullqueue gets
unblocked. In the meantime, the demuxer tries to push on fullqueue, and
is blocking there.

In that case the current code will post a BUFFERING message on the bus when
emptyqueue gets emptied, that leads to the application setting the pipeline state to
PAUSED. So now we end up in a situation where 'laggy downstream' is
prerolled and will not unblock anymore because the pipeline is set to
PAUSED, the fullequeue does not have a chance to be emptied and
the emptyqueue can not get filled anymore so no more BUFERRING message
will be posted and the pipeline is stucked in PAUSED for the eternity.

Making sure that we do not try to "buffer" if one of the single queue
does not need buffering, prevents this situtation from happening though it lets the
oportunity for buffering in all other cases.

That implements a new logic where we need all singlequeue to need
buffering for the multiqueue to actually state buffering is needed,
taking the maximum buffering of the single queue as the reference point.

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

multiqueue: Only handle flow returns < EOS as errors, not e.g. flushing

bin: Use allow-none instead of nullable until we depend on a new enough GI version

bin: gst_bin_new() can accept NULL as name

element: Clarify docs about gst_element_get_request_pad() and remove deprecation part

This function is not really pad or slow for the common case of requesting a
pad with the name of the template. It is only slower if you to name your pads
directly instead of letting the element handle it.

Also there's no reason to deprecate it in favor of a more complicated function
for the common case.

queue2: Post errors if we receive EOS after downstream reported an error

There will be no further data flow that would allow us to propagate the
error upstream, causing nobody at all to post an error message.

queue: Post errors when receiving EOS after downstream returned an error

There might be no further data flow that would allow us to propagate the
error upstream, causing nobody to post an error at all.

multiqueue: Post errors ourselves if they are received after EOS

After EOS there will be no further buffer which could propagate the
error upstream, so nothing is going to post an error message and
the pipeline just idles around.

docs: Trivial pad documentation fix

Presumably a copy-pasto.

concat: Add unit tests for concat element

concat: Add documentation and integrate into documentation build

concat: Add new element that concatenates multiple streams

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

tests: caps: add check for caps with features intersection

Checks that a caps without features doesn't intersect with
one that has features

examples: controller: fix typo in comments

bytereader: use unchecked inline variant for get_remaining in more places

We've already done the g_return_*_if_fail (reader != NULL)
dance in those places, so no need to do it again.

utils: Ghostpads can be request pads too but check if the pad has a template

Otherwise we dereference NULL in some cases and crash.

tests: Add missing unrefs of objects after use

Unreffing the objects returned by gst_bin_get_by_name() and
gst_pipeline_get_use() were missing in several tests, so add these.

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

utils: Fix unititialized variable compiler warning

tests: Add test verifying gst_element_link_pads_full()

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

utils: Unref/release pads in error cases when linking pads

Previously gst_element_link_pads_full() forgot to unreference or release
request pads in several error cases. Also comments were added mentioning
why releasing is not necessary in some places.

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

gstcheck: add docs for gst_check_setup_src_pad_by_name()

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

Makefile: Add usage of build-checks step

Allows building checks without running them

bufferpool: Add missing error checking to default_alloc_buffer()

default_alloc_buffer() calls gst_buffer_new_allocate() but does not check for
failed allocation.

This patch makes default_alloc_buffer() return an error (GST_FLOW_ERROR) if
buffer allocation fails.

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

multiqueue: avoid using infinite buffers limit if finite is requested

If the current max-buffers limit it infinite and a finite value is
requested, switch to the MAX (requested, current-value) to set some
limit but not below what we know that we've needed so far.

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

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

parse: Unref reference to enclosing bins

Previously all reference to enclosing bins of an element were leaked
when doing delaying setting a property.

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

gst-launch: Support SIGINT (Ctrl+C) on W32

W32 has no SIGINT, but it does have SetConsoleCtrlHandler(), which sets up
a handler for Ctrl+C.

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

poll: Prevent false-negative from WAKE_EVENT() on W32

SetEvent() seems to not call SetLastError(0) internally, so checking last
error after calling SetEvent() may return the error from an earlier W32 API
call. Fix this by calling SetlastError(0) explicitly.

Currently WAKE_EVENT() code is cramped into a macro and doesn't look to be
entirely correct. Particularly, it does not check the return value of
SetEvent(), only the thread-local W32 error value. It is likely that SetEvent()
actually just returns non-zero value, but the code mistakenly thinks that the
call has failed, because GetLastError() seems to indicate so.

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

gst: include atomicqueue.h again in gst.h

It's a public header of gstreamer core, so #include <gst/gst.h>
should make the API available.

typefindelement: remove prototype for function that no longer exists

bytereader: add gst_byte_reader_masked_scan_uint32_peek

Adds gst_byte_reader_masked_scan_uint32_peek just like
GstAdapter has a _peek and non _peek version

Upgraded tests to check that the returned value is correct in the
_peek version

API: gst_byte_reader_masked_scan_uint32_peek

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

bufferlist: pre-allocate buffer array in one go with the buffer list

We can now create and free a buffer list with one slice alloc/free
call in most cases, instead of one slice alloc/free for the list,
one slice alloc/free for the GArray, and one malloc/free for the
GArray array. In practice we know the max size of our buffer list
from the start, so can avoid reallocs.

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

private: allow internal access to the debug base-time

Moving the extern to the head lets us access this from other parts as well. This
is neeed in the tracer branch.

scripts: Use git pull --rebase

No point introducing redundant merge commits.

Revert "tests: taglist: add basic test for taglists serialization"

This reverts commit 85d23d19b7de40541d63b0bc76d8b646c321af26.

There was already a gsttag.c tests file, this test has been merged
in it in the previous commit

tests: tag: add the empty taglist serialization test

Adds the test to the appropriate and already existing file.

tests: taglist: add basic test for taglists serialization

Make sure it works with empty taglists

tests: gststructure: serialization of tag event structure

Adds a test that checks that the serialization of a tag event structure
works without problems

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

gstvalue: add GstTagList compare function

When serializing GstStructures from events in GDP it will add a taglist
as a GstStructure field, having the compare function allows comparison of
GstStructures to check if the serialized/deserialized version matches the
original one, among other cases.

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

funnel: Fix for racy EOS event handling

When eos events are forwarded simultaneouly from two sinkpads on
funnel, it doesnot forward the eos to sourcepad. The reason is
sticky events are stored after the event callbacks are returned.
Therefore while one is about to store the sticky events on the its
sinkpad, other sinkpad starts checking for the eos events on all other
sinkpads and assumes eos is not present yet.

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

pipeline: Add unit test for resetting of the start time

Also check if this properly affects basesink elements to not
report the old start time but the real current position when
setting to PAUSED again.

pipeline: Reset the start time when going from PAUSED to READY too

pipeline: Reset start time in READY->PAUSED before chaining up

Otherwise bin will change the state of the child elements without
distributing the new start time.

elements: improve buffer flags to string utility function

Avoid relocations and refactor so that we don't calculate
the fixed and known at compile time maximum string size
every time. Also skip the mini object flags which we are
not going to print anyway.

Back to development

Release 1.4.0

Update .po files

po: Update translations

baseparse: Return FLOW_FLUSHING when pushing a frame on a pad that has been flushed

When going to READY, it is possible that we are still pusing a frame but that
our srcpad has already been set to flushing. In that case we should not
post any error on the bus but instead cleanly return FLOW_FLUSHING.

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

typefindelement: Propagate input buffer PTS and DTS

The initial buffers (that were used for timestamping) might have PTS
and DTS set. In order to forward those properly, get the initial
PTS/DTS from the adapter and set them on the reconstructed output
buffer.

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

debugutils: Unref pad template after use

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

gst: init taglist gtype to use it in gstvalue

Otherwise it will have a 0 value and GstTagList won't be found
for GstValue functions (serialization/deserialization)

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

Release 1.3.91

Update .po files

po: Update translations

docs: Fix documentation typos and inconsistencies

 * GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
 * Expand GST_MESSAGE_DEVICE to the full enum value names
 * Correct the incorrect references to the GstDeviceProvider interfaces
 * Describe caps arguments for gstcheck interface
 * Add missing docs for GstNetAddressMeta and its add function
 * Add docs for toc helper macros
 * Avoid refering to GstValueList type as done elsewhere

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

docs: Cleanup interface references in docs

 * Delete references to removed interfaces
 * Add missing documentation sections
 * Fix duplicate interface references for GstDevice

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

docs: There is no decodebin2 anymore, don't pretend otherwise

fdsrc: fix error setting when uri is invalid

Elements should always set the GError

libs: gstcheck: check that mutex is locked before g_cond_wait*() is called

Sanity check to catch problems in unit test.

libs: gstcheck: init and clear global mutex and cond variables

tests: fix locking in gstpoll unit test

The mutex needs to be locked when g_cond_wait*() is
called.

gst-uninstalled: add video and base library paths from -bad

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

tools: suppress GLib warnings when gst-inspecting deprecated properties

GLib in git will spew a g_warning() when a property marked as
deprecated via param spec flags is accessed. Suppress this by
setting the appropriate environment variable.

message: Work around g-i/pygobject/gjs bug with ~0 in enums

GST_MESSAGE_ANY was considered a long by pygobject and gjs, and thus
couldn't be used in gst_bus_poll() and similar APIs as they expect an
int-typed enum.

Just use 0xffffffff instead for now.

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