Screen: Add additional lossless codecs for GStreamer video writing/recording.

Add support for ‘y4menc’ for near lossless YUV4MPEG raw writeout. This
is only near lossless for grayscale (+/-1 unit error), more lossy for
rgb (+/-6 units due to chroma subsampling), but can be processed by
most oss tools. Essentially this stores raw yuv data in a container,
uncompressed, only chroma spatial subsampled.

‘ffenc_sgi’ is another codec: It RLE encodes images into image/x-sgi
format and dumps them into a stream of images via multipart muxer. The
format is completely lossless for 1, 3, 4 channels, and can compress
well for some pictures, but such files can only be read by Psychtoolbox
or other GStreamer/FFmpeg based tools which provide multipartdemux
support. Also the “stream of images” loses any framerate information,
so playback will always assume a fixed 25 fps and seeking in such a
“movie” is not possible. This format might be good for compressed
storage during live recording, but will need transcoding to make actual
use of data most of the time..

Add a new specialFlag1 setting 256 to Screen(‘Openmovie’) which allows
to disable the deinterlacer, as use of it (even as pure no-op
passthrough!) can incur color format conversions which prevent
lossless’ly stored 8 bit grayscale data from being decoded lossless -
lossy on decoding instead of encoding!

-> Screen for 64-Bit Matlab on OSX rebuilt and tested.
-> LosslessMovieWritingTest.m updated. Now can display min/max error
and error distribution histogram if lossy conversion is detected.
LosslessMovieWritingTest: Mention new lossless codec options in help text.
Screen: Add lossless 16 bpc movie writing/recording support.

This allows to write 16 bpc grayscale and RGB movies vie
Screen(‘CreateMovie’) and the dc1394 video capture/recording engine, by
extending the GStreamer movie writing backend. I couldn’t find any
suitable 16 bpc capable codecs in GStreamer-0.10, so we define our own
proprietary format for this purpose, which can only be read/processed
by PTB, so it is only suitable as an intermediate format. We pack 16
bpc pixels into 8 bpc lossless encoded rgb pixels. For 3 channel we
store high/low bytes of 16 bpc RGB in adjacent RGB8 pixels, using a
double-wide image format. For 1 channels, we store high/low bytes of
successive 16 bpc gray pixels in [RG, B][R, GB] channels of RGB8
pxixels, so 2/3 of RGB8 pixels are needed to store a given number of 16
bit grayscale values. Accomplish this by reducing height of encoded
video to 2/3 the height of input video. A new keyword for movie
encoding options named ‘'UsePTB16BPC’ enables encoding/recordig of such
movies. A new specialFlags1 setting 512 in movie playback’s
Screen(‘Openmovie’) call allows decoding of such movies.

-> LosslessMovieWritingTest.m extended to test proprietary ptb 16 bpc
movie writing.
-> Screen for 64-Bit Matlab on OSX rebuilt and tested.
-> Provides fully lossless 8 bpc and 16 bpc movie encoding with
suitable codecs like huffyuv (aka ffenc_huffyuv) and ffenc_sgi.
-> This is probably as good as it gets for the eol’d GStreamer-0.10
series wrt. to high bit depth support.
-> On synthetic test images, even compressed lossless movies are
slightly larger than raw data would be, about 10% larger. On real
footage this may be a bit better.
-> Performance testing with libdc1394 video capture+recording is tbd.
Screen for Linux rebuilt and tested with LosslessMovieWritingTest.m

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> Small Octave 3.2 backwards compatibility fix for
   LosslessMovieWritingTest.m
-> All 8/16 bpc lossless movie encodings verified to work with test.
Screen: Apply filter-caps also during recording with GStreamer+camerabin1

Now that this is an opt-in via recordingflags 4096, we can also
apply during recording, as the user is in control here.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
VideoCaptureDemo: Allow optional bpc > 8 capture testing.

Via new optional 'bpc' parameter.
VideoRecordingDemo: Small improvements.

- Display class of returned image matrix, so one can see if it is
  uint8 or uint16, depending on bitdepth parameter, which is hard-
  coded to 8 by default.

- Count and display unique pixel values in image, so one can easily
  gauge in 16 bpc mode if actually more than 8 bpc resolution are
  truly achieved - ie., the net-bpc, or if precision gets somewhere
  lost.
Screen: Report 'GetBandwidthUsage' of dc1394 capture in range 0-1.

Use a normalized range of 0.0 to 1.0 for 0% to 100% for reporting
usage of bus bandwidth, instead of bus units.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo.m demonstrates it.
Screen: Allow setup of videosource bin via 'SetVideoCaptureParameter'.

The GStreamer engine can use a gst-launch line bin description for a
videosource if deviceIndex -9 is used. Use a special video capture
parameter setting to define the launch line instead of abusing the
'moviename' in 'OpenVideoCapture'.

E.g.,

Screen('SetVideoCaptureParameter', -1, 'SetNextCaptureBinSpec=dc1394src')

would set 'dc1394src' as the videosource bin to use for creating a
new video capture device via Screen('OpenVideoCapture', -9, ...);

-> Allows concurrent use of video recording and videosource bins.
-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen: Fix error message in PsychWindowSupport.c
Screen rebuilt.
Screen: Make libdc1394 video recording engine multi-threaded.

So far video recording in the Firewire engine was driven
synchronously by the master thread. Extend the implementation,
so that the 'recordingflags & 16' setting allows to run recording
asynchronously in a dedicated realtime background processing thread.

Each camera with active video recording gets its own thread. The
thread runs at realtime priority with a level of +1 wrt. master
thread. The thread periodically polls for new video frames from
the dc1394 capture engine, dequeues them, optionally pre-processes
them (Bayer filtering or YUV->RGB conversion), and pushes them into
the GStreamer video recording pipeline. It also provides the frames
for retrieval by the masterthread via the usual Screen('GetCapturedImage')
function.

If low-latency "frame dropping" capture is requested in
Screen('StartCapture',...), the thread will poll at 1 msec intervals,
push all captured frames to video encoding, but only provide the
most recently deqeued frame in a special bounce buffer "current_frame",
so that the master thread will always only get that frame.

Non-dropping mode is tbd. It modifies the GStreamer pipeline to
feed all video frames into an additional appsink with sufficient
capacity and the master thread will pull frames from the appsink
in FIFO order, so no frames ever get lost for the consuming script.

Regular synchronous "old school" recording and capture is still used
if no async recording is requested.

The current implementation works reasonably well when tested with
sync / async recording, single camera and multi-camera, free-running,
bus-synced or ttl-synced. What is missing is a little bit of logic to
make sure each thread pulls the same amount of frames when capture
is stopped. This is not an issue in hw-synced mode, but a small issue
in bus/software-synced mode. In synced mode, all cameras stop their
capture at the same time and therefore all DMA queues contain the same
amount of pending frames at end of capture, but as the threads stop
at slightly different points in time, they will be able to pull and
encode different numbers of those frames from the DMA queues before
they die. This needs to be solved by explicite use of some barrier.

-> Screen.mex for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo.m extended with multicam recording support.