stbt.{Match,Motion}Timeout debug output shows values < 1

If you used `wait_for_match(..., timeout_secs=0.5)` the MatchTimeout
exception's message was "Didn't find match for ... within 0 seconds".

Note that stbt doesn't currently guarantee to process every frame
of video, so very small values for timeout_secs aren't as useful as you
might think. stbt does guarantee to process at least one frame (even if
`timeout_secs=0`).
stbt.MatchTimeout: Avoid verbose numpy representation

...of the template image (in the MatchTimeout exception message) when
the image was given as a numpy array (not a filename).

Commit 2c276e36 added the ability to pass a numpy array as a template
image to `wait_for_match` and other matching functions. But if no match
was found, the output was unnecessarily verbose:

    MatchTimeout: Didn't find match for '[[[255 255 255]
      [255 255 255]
      <snip>
      [176 176 176]]]' within 10 seconds.
Gstreamer 1.0: Improve performance back to pre-1.0 days

When migrating to GStreamer 1.0 we introduced a performance regression
slowing down stb-tester by a factor of 4 or so.  Based on profiling this
was due to it being slow to create buffers (`Gst.Buffer.new_wrapped`) from
the numpy arrays as required for drawing notes on the saved/displayed
video.  My best guess is that instead of doing a straight `memcpy` it was
iterating through each element copying a byte at a time.

This commit fixes these performance issues increases performance back to
stb-tester 0.18 levels.

Unfortunately some of the code is a little hairy.  The proper way to do
this with GStreamer 1.0 is to use `gst_buffer_map()` and access the data
through the returned `GstMapInfo` struct.  Unfortunately the `GstMapInfo`
isn't properly exposed in Python (see [bz #678663]) so instead I use
ctypes to call it more manually.  Note: this issue should be fixed in the
(as yet) unreleased python-gobject 3.12 (see [bz #710561]).

Every `gst_buffer_map()` must be accompanied with a `gst_buffer_unmap()`
and the data must only be accessed between these two calls.  To enforce
this in Python we use a `contextmanager` although this isn't perfect.
This means that the numpy array should not be used outside of the `with:`
statement and the data should be copied instead using `numpy.ndarray.copy`.

[bz #678663]: https://bugzilla.gnome.org/show_bug.cgi?id=678663
[bz #710561]: https://bugzilla.gnome.org/show_bug.cgi?id=710561
Display: Use GstSample in place of (numpy.ndarray, timestamp)

This commit increases performance by ~10% vs. stb-tester 0.18.  We do this
by avoiding copys.  Internally the numpy arrays are backed by the data
directly in the `Gst.Buffer`s.  Instead of 3 copies made during
`detect_match` only one is made now.

Internally we are now passing GstSample around instead of the (data,
timestamp) tuple.  This will be useful in the future the future for
synchronising readings against wall clock time as the `GstSegment`
associated with the buffer is required to correctly interpret the
timestamp.
gst_hacks.py compatibility with OS X

Dynamic libraries are ".dylib" not ".so" on OS X.

If I only do `ctypes.CDLL("libgstreamer-1.0.dylib")`, `dlopen` won't
find the library in `/opt/local/lib` (where GStreamer is installed by
the "macports" package manager), even though I'm using
`/opt/local/bin/python`. Adding `/opt/local/lib` to `DYLD_LIBRARY_PATH`
doesn't work either, I get all sorts of "Symbol not found" errors. So
I'm calculating the path from where GStreamer's GObject-Introspection
typelib data is installed. I've only tested this with macports.
Merge pull request #119 from wmanley/gst-1.0-performance-nocopy

Gstreamer 1.0: Improve performance back to pre-1.0 days
Fix test_wait_for_match interlacing issue on OS X

On my OS X system the video seen by stbt has fine horizontal lines
through it -- some kind of interlacing problem. I can reproduce this
with the following gst-launch command, but only on my OS X system, not
on Linux. I don't know if the problem is platform-specific, to do with
my video sink, or just a bug in my specific version of GStreamer.

    gst-launch-1.0 videotestsrc ! \
        video/x-raw,format=I420,width=320,height=240 ! videoconvert ! \
        video/x-raw,format=BGR ! videoconvert ! autovideosink

(The conversion to BGR and back is to mimic what stbt does in its
internal pipeline; without that I can't reproduce the problem.)

Removing "format=I420" fixes the problem. On 0.10, "video/x-raw-yuv" was
necessary to be able to specify the width & height caps but it seems
that on 1.0 we only need "video/raw" and the format can be left
unspecified.
Revert is_screen_black.threshold change from a071a9cc

a071a9cc (Port to Gstreamer 1.0) increased is_screen_black.threshold
with the following comment:

> I've had to increase the default threshold in is_screen_black test as it
> seems, possibly with the move from `video/x-raw-yuv` to
> `video/x-raw,format=I420` that blacks aren't as black anymore, possibly
> as a result of GStreamer 1.0 choosing a different type of yuv in 0.10 or
> possibly due to changes introduced during the ffmpegcolorspace ->
> videoconvert change.

This isn't necessary after the previous commit (Fix test_wait_for_match
interlacing issue on OS X) which removed "format=I420" from the
self-tests' source-pipeline. Presumably the increased threshold won't
be necessary with real video-capture hardware either.
Merge pull request #121 from drothlis/fix-selftest-interlacing

Fix test_wait_for_match interlacing issue on OS X
README.rst: Update to match 1f0a74ce

This commit is the result of running `make doc` after the change in
1f0a74ce.
stbt.wait_for_match per-frame debug output includes template filename

For long-running `wait_for_match` calls (for example with
`timeout_secs=120`) I find it really annoying to have to scroll up in
the log to find what image it's searching for. This will make the logs
much more verbose (particularly because the image path is an absolute
path†) but that's a problem that can be solved in the log-viewing tools
(turn off line-wrapping in `less`; we'll have to come up with a solution
when viewing the logs in the browser.)

† Perhaps we can truncate the path at the boundary of the git
repository, like `stbt batch run` does when reporting the test script's
filename.

`MatchResult.image` is the same thing that you passed to
`wait_for_match`: Either a string or a `numpy.ndarray`. But if it's a
string, `MatchResult.image` is slightly different than what you passed
to `wait_for_match`: `MatchResult.image` is an *absolute* path, because
you might want to use it in a different stack frame than where you
called `wait_for_match` (relative template image paths are resolved
relative to the caller of `wait_for_match` -- see `stbt._find_path` and
4e5cd23c).
Merge pull request #104 from drothlis/wait-for-match-debug-includes-template-filename

stbt.wait_for_match per-frame debug output includes template filename
stbt.py: Cleanup import ordering

According to http://legacy.python.org/dev/peps/pep-0008/#imports
(first imports from the standard library, then third party libraries,
then the local application's libraries).
test_save_video: Avoid infinite loop if match fails

This self-test uses `stbt run --save-video video.webm` to create a
video, then verifies the video with a `wait_for_match` against a source
pipeline of "filesrc location=video.webm". For some reason (high CPU
load at the time resulted in a low-quality saved video?) the
`wait_for_match` failed, but the EOS from the end of the video would
cause stbt to restart the source pipeline, thus playing the video again
and restarting the timestamps in such a way that the `wait_for_match`
timeout was never triggered.

Longer term, we want to use some GStreamer mechanism to relate the
buffer's timestamp to the system (wall clock) time. We also want to
avoid restarting the source pipeline for non-live sources. For now this
commit will prevent this self-test from going into an infinite loop if
it fails. There are no other self-tests using filesrc with a video.
test_that_video_index_is_written_on_eos is robust under load

When running tests in parallel, this test would occasionally fail with:

    File "webminspector/webminspector.py", line 116, in <module>
      main()
    File "webminspector/webminspector.py", line 97, in main
      pos = segment.SearchLevelOneElements(file_, pos)
    File "webminspector/webm.py", line 560, in SearchLevelOneElements
      size, start_pos = ReadOneByteForElementIdSize(file_, pos)
    File "webminspector/webm.py", line 53, in ReadOneByteForElementIdSize
      file_.seek(pos)
    TypeError: 'NoneType' object cannot be interpreted as an index

Presumably `stbt run` didn't manage to send sufficient data for the
video to be written properly.

This commit re-runs the test with a longer `sleep` if it fails the first
time. I didn't simply increase the timeout because this test doesn't
usually fail when running the tests sequentially (if you don't have GNU
`parallel` installed), so I didn't want to increase the run-time of
a sequential `make check` unnecessarily.
rpm spec file: Add missing dependency "python-flask"

Used by `stbt batch instaweb`.

Note that python-jinja2 is implicitly installed by python-flask, but
I've kept python-jinja2 as an explicit dependency of stb-tester because
stbt.py uses jinja2 outside of flask (to generate the debug html files
from `stbt run -vv`).
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.