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.
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
Update .po files
Release 1.4.1
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
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
devicemonitor: fix typo in sample code in docs

https://bugzilla.gnome.org/show_bug.cgi?id=735975
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
valve: fix typo in description

https://bugzilla.gnome.org/show_bug.cgi?id=736455
query: add annotations to gst_query_set_nth_allocation_pool()

https://bugzilla.gnome.org//show_bug.cgi?id=736424
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.
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
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
query: Add annotations to gst_query_add_allocation_pool()

https://bugzilla.gnome.org/show_bug.cgi?id=736736
event: add annotations to gst_event_parse_toc_select()

https://bugzilla.gnome.org/show_bug.cgi?id=736739
typefindelement: do not leak sticky events in flush_stop

https://bugzilla.gnome.org/show_bug.cgi?id=736813
docs: pwg: fix some links to the API docs

https://bugzilla.gnome.org/show_bug.cgi?id=736762
Update .po files
Release 1.4.2
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