baseparse: don't leak caps in gst_base_parse_process_streamheader

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

tests: baseparse: set_sink_caps vfunc should't take ownership of the caps

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

fakesrc: mark the pattern property as unused

Revert the previous commit which removes the pattern property of fakesrc because
doing so will break ABI. Bringing the property back but marking it as unused
in the property string.

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

Revert "baseparse: don't leak caps in gst_base_parse_process_streamheader"

This reverts commit 5e8b4bf085180f7a4c7ae6ec0f525baeaedd4df8.

This causes refcounting criticals in the baseparse unit test.

fakesrc: removing unused pattern option

Eventhough the "pattern" property of fakesrc can be set, it is never used. The
only pattern supported is the default 0x00 -> 0xff, and if a pattern is set by
the user it is ignored. Removing the unused property and variable.

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

queue: Add missing break in switch

queue: update segment position on GAP events to calculate levels properly

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

queue2: update segment position on GAP events to calculate levels properly

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

multiqueue: update segment position on GAP events to calculate levels properly

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

baseparse: don't leak caps in gst_base_parse_process_streamheader

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

capsfilter: Push pending events before a buffer also if upstream never configured caps but we have srcpad caps already

Otherwise we never send pending events downstream that arrive after we
configured caps on the srcpad.

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

uri: Don't unconditionally use g_list_copy_deep()

We don't depend on GLib 2.34 yet and just for this seems a bit useless.

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

uri: Include our own BSD licensed copy of strcasestr() for Windows and others

uri: Fix compiler warnings with gcc

These are actually not true.

gsturi.c: In function '_gst_uri_string_to_table.constprop':
gsturi.c:1316:27: error: 'pct_kv_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
             for (next_sep = strcasestr (value, pct_kv_sep); next_sep;
                           ^
gsturi.c:1283:24: error: 'pct_part_sep' may be used uninitialized in this function [-Werror=maybe-uninitialized]
               next_sep = strcasestr (next_sep + 1, pct_part_sep)) {
                        ^

uri: Fix memory leak in gst_uri_join()

The merged path segments are a deep-copied list and we need to free the
contained strings too instead of just the list nodes themselves.

GstUri: Add GstUri miniobject to handle URIs in an RFC 3986 compliant fashion

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

scripts: add gst-rpicamsrc to gst-uninstalled

fixme: bump leftover 0.11 fixme comments

event: 'newsegment' to 'segment' in the docs

Brings the api-docs in sync with the 1.0 api rename.

basesrc: move the quick return up

Don't assign local vars if we skip anyway. Add logging for failure conditio

tests: parallelise 'make valgrind'

Use $(MAKE) instead of 'make' inside the Makefile,
otherwise the make will run as if -j1 had been
specified and complain about the job server not
being available, and with $(MAKE) in inherits the
parent make's settings it seems.

Upgrade common submodule for parallel check-valgrind.

Let this settle a bit before upgrading the other modules.

win32: update .def file

It's sorted. If it's unsorted, make check-exports fails.

info: remove confusing warning about running under valgrind

We're not actually doing anything differently anywhere when
we detect that we're running under valgrind, so let's not
print that confusing message that makes people wonder how
they can switch it off so they can valgrind the normal
code paths. Seeing that we're not doing that nor have done
so in the last 10 years we might just as well remove the
entire check actually.

tests: fix caps leak in baseparse unit test

flowcombiner: add a gst_flow_combiner_clear() method

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

API: gst_flow_combiner_clear()

scripts: Handle gst-python in gst-uninstalled

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

capsfilter: Remove EOS event from pending_event list on FLUSH_STOP

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

docs: Fix GstBuffer typo "memory bock" -> "memory block"

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

docs: Improve gst_buffer_get_meta() to clear up confusion

I was confused by the existence of `gst_buffer_get_meta` as it suggested
to me that you should only attach one of any type of GstMeta to a buffer.
It's perfectly fine to attach multiple from a single API so I'm
documenting that here.

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

datetime: added missing include directives

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

queue: Do not forget to release the QUEUE_LOCK in the out_flow_error path

Avoiding deadlocks!

docs: fix a small contradition in the docs

The vmethod get_size() shall return the size in 'format' as configured by
_set_format().

queue: Do not hold GST_QUEUE_LOCK while posting ERROR messages

This might create deadlocks and we need to avoid holding element
specific lock while posting messages

For example a deadlock will happen if while posting the message,
someone connected on the bus (sync) tries to DOT the pipeline.

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

queue2: do not post buffering messages holding the lock

It might cause deadlocks to post messages while holding the queue2
lock. To avoid this a new boolean flag is set whenever a new
buffering percent is found. The message is posted after the lock
is 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=736969

gsturi: Remove unnecessary code

gst_uri_handler_set_uri() function has new_uri, location and colon
are not necessary, they can be removed.

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

docs: pwg: fix some links to the API docs

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

filesrc: remove FIXME

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

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