Screen/GStreamer: Make movie bus message handling more robust.

If message processing is called, always iterate and handle all messages
until no more messages are pending on the bus. The doWait flag only
determines what should be done if there aren't any new messages pending,
ie., if call should return immediately or wait for up to 2 seconds.

Add an additional call to bus event processing in one of the while()
loops that
wait for new frames to arrive - in one of the retry loops.

Also a new routine to check if a movie is seekable, and some code
reformatting.
Additionally reduce verbosity level for rewind related status messages
from 6 to 5.
SphereProjectionShader.frag.txt: Fix off-by-one corner case bug.

See the thread ending in ptb forum message #16071 for the problem and
this field-tested solution.
Screen/GStreamer: Fix a compiler warning in video capture support.

By making a cast to GST_BIN explicit.
Screen/GStreamer: Fix looped movie playback the ump'teenth time.

When it comes to looped playback of movies with GStreamer, apparently
one size doesn't fit all :-(. Our old strategy worked on some system
setups
with some movie files but not others.

So we now make the loop strategy configurable, with a default setting
that at least plays our demo DualDiscs.mov and a few other movies with
H264 video + AAC audio + Quicktime container reliably in looped mode.
Before, that combination was troublesome, sometimes losing sound output
on all iterations but the first, or screwing playback timing from the
2nd iteration,
or hanging until timeout. Some GStreamer installations hadn't trouble
with those
files, but others did - notably the GStreamer SDK. Therefore it is not
clear if our
old code was buggy and only worked by accident, or if the SDK is buggy
and our
code was correct, or any combination of the two.

The old default setup used segment-seeks without flusing the pipeline,
responding to segment done messages on the bus. The new default
setup uses standard seeks, responding to eos messages on the bus,
flushing the pipeline during the seek.

New 'specialflags1' settings 32, 64, 128 during 'OpenMovie' or loop flag
settings 2,4,8 during 'PlayMovie' allow to override the default
strategy to
use segment seeks triggered by segment done messages instead of regular
seeks triggered by eos, and/or flushing the pipeline during the seek,
or using
uri injection method in response to "about-to-finish" signals from
playbin2
instead of seeks -- essentially reloading the movie instead of
rewinding it to
implement a repetition.

My test set of movies shows that different strategies are needed for
gapless
reliable looped playback. E.g., our new seek on eos, with flush seems
to work
somewhat robust, but when used with some avi files it causes gaps
between
repetitions of movies, sometimes lasting fractions of a second, whereas
segment
seeks on end-of-segment without flushing provide perfectly gapless
playback of
those specific files. This is one of those cases where the specific
encoding
parameters and codec/muxer choice for material seem to require
different methods
of looping for best results.

This commit also updates the help texts of 'OpenMovie' and 'Playmovie'
to remove comments related to our old and dead Quicktime playback
engine.

-> Tested on OSX with Gstreamer SDK 2013.6 so far.
-> LoadMovieIntoTexturesDemo still hangs in our DualDiscs.mov. That is a
separate problem.
Screen/GStreamer: Fix passive frame fetching aka LoadMovieIntoTexturesDemo.

Make it work not only with other runtimes, but also with GStreamer SDK.
We follow the recommendation of basic GStreamer SDK tutorial 13 to only
send the seek event for frame stepping to the videosink, not to the
playbin2
itself. This seems to fix all the fetch failures, seek failures and
deadlocks we
experienced with our demo movie DualDiscs.mov or some other movies that
have sound tracks. Tested on OSX with SDK 2013.6.

Also improve error handling for step seeks and reduce timeout from 30
secs to
10 secs.

-> Screen for Matlab and Octave on OSX rebuilt and tested.
Screen: Fix wrong usage of OpenML defective flag.

Was checking for presence of kPsychOpenMLDefective flag in gfxcaps
variable instead of specialFlags in a few instances! This would output
a few wrong diagnostic messages in unlikely corner cases. It would also
choose the less precise / noise resistant timestamping path when our
homegrown frame-sequential stereo mode is in use on Linux + FOSS
drivers,
or during initial video refresh rate calibration. The latter is
problematic as
it will increase sensitivity to timing noise. This was detected when
testing
on Ubuntu 12.04.2 with an ancient RS480 gpu in an ancient laptop with
old
cpu and low ram memory. Bug went probably unnoticed due to its effect
mostly on very old hardware.

-> None of the possible symptoms is critical, so we'll just fold this
into
a future release.
Core: Fix build failure with gcc-4.8+ on octave.

Move #include of PsychConstants.h out of extern "C" block in Psych.h:

We are building PsychScriptingGlue.cc as C++ file. PsychConstants.h
includes PsychInclues.h, which includes mex.h, which on octave causes
build failure with
gcc version 4.8 or later due to some mixup caused by C++ compiling
include files
internal to octave but within the extern "c" block.

-> Move it out of extern "c" block to hopefully make it work. Test by
Debian pending.
-> Continues to build properly against Octave and Matlab inside the
Debian 6.0 VM with
gcc-4.4, and also in the Ubuntu VM with gcc-4.7
-> There is no real need for us to build PsychScriptingGlue.cc as C++
file. This
was done to allow building .oct files for Octave-2, but we don't
support this option
anymore since many years, and building against Octave-3's mex api works
just
fine for a pure C-Compile. We do this since quite a while on OSX +
octave.
Matlab never required a C++ build, and we don't do that on Windows.

-> Screen mex files for 32/64-Bit Octave and Matlab on Linux rebuilt
and tested.
-> Includes Linux OpenML timestamping fixes and some GStreamer changes.
Screen/GStreamer: Try (unsuccessfully) to make movie writing robust on Windows.

This tries to make movie file writing on Windows with the GStreamer SDK
robust.
Unfortunately it fails at it. The changes are supposed to potentially
increase robustness,
and as testing on OSX confirms, they don't hurt. However, the whole
thing doesn't
work any better on Windows (64-Bit Matlab with 2013.6 SDK). Writing a
valid movie
file curiously works, but Matlab hangs at the end of the writing
session and never
recovers.

Screen for OSX 64-Bit Matlab and octave as well as 64-Bit Matlab on
Windows rebuilt.
These changes are also included in the rebuilt Screen mex files from
previous commit.