stbt.py: Fix debug message introduced in 5a0770e6

This was printing "/GstPipeline:pipeline0 (gst.Pipeline)" instead of the
textual pipeline.
stbt.py: Refactor: Move restartable source_pipeline code

So that the pipeline is parsed *after* the main application pipeline is
playing. This will make the next commit easier to understand. The
current commit only moves the code around; it doesn't make any other
changes except renaming the local variable "source" to
"restartable_source" for clarity.
stbt.py: "restart_source" behaviour chooses a free port

Instead of using GStreamer's udpsink/udpsrc default port of 4951.
This allows using multiple HD PVRs on the same PC at once.

We let the application pipeline's udpsrc pick its own port; we can
find out which port it picked by querying the "port" property once the
pipeline has reached at least the PAUSED state. See
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-udpsrc.html#gst-plugins-good-plugins-udpsrc.description

See commit 5a0770e6 for more details on "restart_source".
stbt.py: Trigger source restarts from underruns in the *application* pipeline

Not from underruns in the *source* pipeline. This should catch any
problems in the communication between the source and application
pipelines, not just problems within the source pipeline itself.

I don't think I've seen any actual problem that this solves, but it
seems more robust this way, and the code reflects more closely
the *goal* of the source restarting behaviour.
stbt.Display.frames: Ignore buffers with timestamp == MAX_UNSIGNED_INT

Occasionally, immediately after a restart† the HD PVR delivers *one*
frame with a correct timestamp (which sets "self.start_timestamp" here
in "frames") followed by one frame with a timestamp of
18446744073709551615 (2^64 - 1). This caused "frames" to time out
immediately.

"sys.maxsize" is the maximum *signed* integer, i.e. 2^(n-1) - 1.
The maximum unsigned integer is 2^n - 1 == 2 * (2^(n-1) - 1) + 1.

† See commit 5a0770e6.
tests: Increase timeouts

These tests are all expected to complete quickly, so the increased
timeout doesn't increase the run time of the test suite under normal
conditions. It does avoid some false failures when the system is under
heavy load.
Revert "Source-restart-on-video-loss behaviour is configurable, uses separate pipeline"

This reverts commit 5a0770e6, along with the fixes to 5a0770e6 in
d633efa8, 43de8794, 04728a52, 6f314688, and 54ac51a8.

Because 5a0770e6 isn't 100% reliable:

* The video stream sometimes displays a static image after the pipeline
  is restarted. I *think* this only affects the xvimagesink, because the
  application pipeline continues to process frames and finds, e.g. the
  UI main menu when I press the "MENU" button, even though I don't see
  it on the xvimagesink output. The application pipeline certainly does
  receive frames of some sort, judging from the debug output from
  "wait_for_match".

* Seeking in the video recorded by "stbt run --save-video" doesn't
  always work in the part of the video after a source restart.

* On a heavily loaded system the UDP transport (which is for getting
  frames from the source pipeline to the application pipeline) starts
  dropping keyframes so the received video is unusable for image
  comparison purposes.

* 5a0770e6 breaks the end-of-stream teardown introduced in b7a37493
  when the source device is a Blackmagic video-capture card (with
  "restart_source = False"). The output from "stbt run" is:

      stbt-run: teardown: Sending eos
      stbt-run: glib thread: reporting exception to user thread:
          Internal GStreamer error: negotiation problem.
      gstdecklinksrc.cpp(1248): gst_decklink_src_task ():
          /GstPipeline:pipeline0/GstDecklinkSrc:decklinksrc0

  whereupon "stbt run" exits immediately and the video index is not
  written so the saved video is not streamable.

Maybe the solution to the first 3 points will be to send raw video over
a protocol like RTP, and the solution to the last point will be to put
the decklinksrc in a separate bin, like the pre-5a0770e6 implementation
even though the separate bin isn't used for the source restarting
mechanism. But I don't have time to pursue this any further, so for now
I'm reverting this.
stbt.py: Source-restart-on-video-loss behaviour is configurable

Commit 5a0770e6 made this behaviour configurable *and* also changed the
way source restarting is done. 5a0770e6 was reverted in a189e0c9 because
the new way of restarting the source was unreliable. This current commit
applies the configurability changes from 5a0770e6 without changing the
source restarting mechanism.

We want this to be configurable because some video sources don't *need*
this behaviour. Only the Hauppauge HD PVR needs it. With the Blackmagic,
for example, we prefer to block until video is re-established (or until
"stbt.Display.get_frame" times out) because it is simpler, the logs are
less polluted with "stopping"/"starting" messages, and if you're
recording a video with "--save-video" the video only contains what
happened since the last restart.

Note that the config value accepts "1", "yes", "true", or "on" (case
insensitively), unlike 5a0770e6 which only accepted "True". This is
consistent with ConfigParser.getboolean -- unfortunately our
"get_config" wrapper around ConfigParser doesn't allow us to call
getboolean directly.
stbt-completion: Fix completion of "--save-video"

This was missing from 2ee7b00.
stbt.py: Cleanup: Use "1e9" instead of "1000000000"

It's easier to read, and less likely to have an incorrect number of
zeros. "1e9" is a floating-point value instead of an integer, but here
it doesn't matter.
stbt.Display.frames: Debug message showing timestamp when timed out

In case we see the behaviour described in d633efa8 again after a189e0c9.
stbt.Display.restart_source_bin: Don't sleep in the GLib main loop's thread

So that pressing Control-C while the pipeline is being restarted will
(most likely) be caught by the main application thread, not the GLib
thread, and thus the application will actually exit.
stbt.Display.teardown: Avoid intermittent error from decklinksrc

Occasionally, on teardown the following GStreamer error would happen
*before* the pipeline received the EOS event, so if a video was being
recorded it wouldn't have the index information necessary for seeking.

    Internal GStreamer error: negotiation problem.
    gstdecklinksrc.cpp(1248): gst_decklink_src_task ():
      /GstPipeline:stb-tester/GstBin:bin0/GstDecklinkSrc:decklinksrc0

It is still necessary to post an EOS message to the source bin, even
after unlinking it from the sink bin (see b7a37493).

I tested this with:

    while ./stbt-run --save-video video.webm -vv test.py &&
          webminspector.py video.webm | grep 'Cue Point';
    do
        :
    done

which would fail after 3 or 4 runs before this commit, and succeeded 50
times with this commit. See b7a37493 for details on webminspector.py.