tests/test-stbt-batch.sh: Increase timeouts

Self-tests that are testing that `stbt batch run` (without `-1`) keeps
on running until one of the test scripts fails, have a timeout to avoid
the self-test running forever in the (hypothetical) presence of a bug
in `stbt batch run`. This timeout needs to be increased for systems that
are running the self-tests while under heavy load. The increased timeout
shouldn't make any difference to the run-time of these self-tests in the
normal (successful) case.

Thanks to Lewis Haley for reporting the problem:

> I got false negatives for these tests because they were timing out
> before they could conclude. This was probably due to my system having
> a heavy load at the time (running tests with extra logging processes)
> and the stb-tester selftests in parallel.

I also did some related cleanup: I added the `-1` argument to a
self-test that isn't explicitly testing the exit-on-failure behaviour,
but was relying on the fact that `tests/test.py` returns failure the
second time it is run. And I added a timeout to all remaining self-tests
that call `stbt batch run` without `-1`, for consistency.
stbt control: Detect duplicated keyboard keys in the keymap file

If a user assigns multiple remote control keys to a keyboard key in the
keymap file, like

    o   OPEN
    o   OK

`stbt control` silently ignores this configuration issue and only
uses the mapping that is specified later in the keymap file.

Rase `stbt.ConfigurationError` if a keyboard key is duplicated.
Merge pull request #123 from szemate/stbt-control-to-detect-duplicated-key

stbt control: Detect duplicated keyboard keys in the keymap file
stbt.py: Document that GObject.threads_init() won't be needed forever

See
https://help.gnome.org/misc/release-notes/3.12/developers.html.en#pygobject

For the foreseeable future we still have to support GObject < 3.12.
stbt.py: Fix teardown hang with BlackMagic Intensity Pro

Since the port to GStreamer 1.0 the BlackMagic Intensity Pro has caused
an intermittant hang during pipeline teardown (after the test script has
run to completion).  While it should be valid to call

    source_pipeline.set_state(Gst.State.NULL)

at any time this was hanging.

It seems from the backtraces that the `GstBaseSrc` thread that was
associated with `decklinksrc` was blocked calling `gst_task_join`, e.g.
waiting for the BlackMagic thread to finish.  In turn there was another
thread (presumably the target of the join) calling into the proprietary
BlackMagic blob which seemed to be just blocked on `poll()`, presumably as
part of an event loop.  There must be some sort of race condition in there.

Instead we shut the pipeline down more gently by first sending EOS to the
source pipeline and then only after receiving EOS from our `appsink` do we
precede to state NULL.  This way we can be certain that the pipeline is
quiescent before attempting the state change.   This seems to fix the hang.

Fixes #110
Merge pull request #124 from wmanley/blackmagic-fixes

stbt.py: Fix teardown hang with BlackMagic Intensity Pro
fixup! stbt.py: Fix teardown hang with BlackMagic Intensity Pro

Fix a race in the recently modified teardown code.  With further testing
with the Teradek VidiU I got the error:

    stbt-run: teardown: Source pipeline did not teardown gracefully
    Traceback (most recent call last):

      File "stbt.py", line 1408, in teardown
        self.source_pipeline.set_state(Gst.State.NULL)
    AttributeError: 'NoneType' object has no attribute 'set_state'

As `rtmpsrc` has its own teardown problems (see #111).
Allow user_pipeline to output compressed video

This commit relaxes the requirements of the user provided source pipeline.
Previously it had to provide raw video frames whereas now stbt does
decoding itself.  This is convenient for users but the real advantage is
that it allows us to buffer more intelligently.

raw video takes up lots of memory but it's very easy to manipulate.  You
can drop any frame (`GstBuffer`) and it will have no effect on the meaning
of any previous or subsequent frames.  Compressed video is the opposite.
If you drop buffers in an h264 stream you will see artefacts until the next
I frame comes along.

stbt has some queues set to leaky as our processing can be slower than the
rate at which frames arrive.  It is usually more important that the video
frames being analysed are recent rather than consecutive so we drop frames.
With this commit we are a little more selective and ensure that we only
drop decoded frames rather than compressed ones to avoid artefacts, even
under load.  This makes the assumption that your machine can comfortable
decode video in real time.

This is required to implement smart-tv-support where we wish to operate on
decoded frames but want to avoid dropping any frames that we've done
expensive transformations on - if we have to drop frames under load we
prefer to do it as early as possible in the pipeline to waste the minimum
amount of CPU time.  With this we will be able to insert an additional
transformation pipeline between the leaky queue and stbt's algorithms.

This feature also lays the groundwork for a performance measurement mode
where you don't want to drop any frames as you want to analyse them all,
for instance to measure animation smoothness.  This should now be possible
without having to buffer (potentially GBs of) raw frames in memory.

This is still not perfect.  Ideally in the future we will be able to drop
frames even before decoding them if we can identify that dropping them will
not produce artifacts.  This could be accomplished with a parser (e.g.
h264parse) and flushing the non-leaky queue every time a non-delta frame
is inserted.  But this commit works well enough for now.

With this change (specifically the explicit support for non-live sources)
`tests/run-performance-test.sh` once again gives useful results.  It had
been broken since the port to GStreamer 1.0 - although note: it probably
doesn't make sense to compare performance across this change.

I had to modify the source pipelines in the black-screen tests because in
those cases the GStreamer pipeline now contains a decodebin where there
was none before.  So previously during caps negotiation videotestsrc would
ask down the pipeline what the prefered caps are and the appsrc at the end
would reply "'video/x-raw,format=BGR' please" so videotestsrc would send it
in that format.  The purpose of decodebin is to take any format and
provide the data in a raw format.  So now the new decodebin replys to the
videotestsrc's caps query with "'ANY' caps are fine thanks!" and
videotestsrc defaults to "video/x-raw,format=I420" which has a subsampled
chroma.  This causes problems as with subsampling edges aren't as sharp
which can cause masks to fail among other issues.  See 1f0a74c for a
related change.
stbt.py: Add transformation pipeline

The transformation pipeline allows a transformation to be made on input
video to stb-tester.  This will be useful for Smart TV support as the
source_pipeline in this case is a video from a camera pointing at a TV
but we want to transform it such that stb-tester operates on what is
being displayed on the TV screen.

It is not possible to append such a transformation to source_pipeline
itself because there is a leaky queue after the source_pipeline.  This
leaky queue exists because stbt's image processing algorithms aren't fast
enough to analyse every frame in real time.  By dropping frames
(particularly when under load) we keep up with the live source.
Unfortunately the transformations required to undistort the image of a TV
can themselves cause significant load.  This was causing a runaway effect
where the image transformations would cause load, slowing the ability for
the image processing to read frames, causing frames to be dropped and all
the work that went into creating the frames to be thrown away.

This transformation pipeline is inserted **after** the leaky queue so we
are guaranteed that every frame we transform will be processed by stbt.
As such we must be very careful what we put in the transformation pipeline:
queues (buffers) will introduce latency so should be avoided if possible.
For now it's safer to consider it for internal use only.