Screen/GStreamer videocapture: Update comments in codec setup.

So they reflect reality for huffyuv Huffmann YUV encoder and ljpeg
lossless JPEG encoder.
Screen: Allow lossless writing of movies with 1, 3 or 4 layers and 8 or 16 bpc.

The Screen(‘CreateMovie’) function now optionally accepts a target
number of color channels (1 = Red/Grayscale, 3 = RGB, 4 = RGBA) instead
of using a fixed RGBA layout. It also accepts an optional bitdepth
argument to allow for 8 bpc or 16 bpc encoding, instead of the
previously fixed 8 bpc. Screen(‘AddFrameToMovie’) can now readback the
framebuffer as Red or RGB in addition to the old RGBA, and readback 16
bpc data in addition to the old 8 bpc. Exception is embedded OpenGL-ES
graphics, where only 8 bpc RGB or RGBA is supported, but not 16 bpc or
Red only.

-> The movie writing functions strive to writeout data in the requested
format and layout. This makes 8/16 bpc writeout and pure grayscale or
RGB writeout possible if suitable codecs and muxers are selected for
encoding. Optimizations are in place for the ffenc_huffyuv and
ffenc_ljpeg encoders: These are lossless codecs, so we try to feed them
data in a format that actually allows lossless encoding, at least for 8
bpc color resolution. Only certain color caps and color channel layouts
allow this.

-> These codecs are supposed to be lossless, but verification of this
hypothesis is pending.
-> These codecs only support 8 bpc, so 16 bpc so far leads to loss of
precision down to 8 bpc. Still hunting for a 16 bpc capable
encoding/codec that actually works.
-> The huffyuv codec works well for en/decoding and playback, but
produces relatively large files, with only ~ 2x compression for RGB and
almost no compression for Grayscale. The ljpeg codec provides higher
compressions of 2x - 4x, but GStreamer can’t decode ljpeg data, so this
is problematic for ptb use. vlc can decode such movies, so apparently
encoding works, but we’d need a transcoding step to use such footage in
ptb.

-> Screen for 64-Bit Matlab on OSX rebuilt and tested.
Screen: Fix lossless 8 bpc grayscale encoding, add proper test.

New testscript LosslessMovieWritingTest.m allows to test if movie
writing works lossless. So far, only 8 bpc testing is implemented.
The test showed that ffenc_huffyuv can’t encode 8 bit grayscale
lossless, most likely not the codecs fault, but because the colorspace
converter converts from x-raw-gray to x-raw-yuv Y42B format and incurs
some roundoff errors during conversion. Now we force conversion from 8
bpp/bpc gray to 32bpp/bpc RGB8 by replicating the grayscale value into
R,G,B. This avoids lossy color space conversion and yields truly
lossless grayscale encoding, at the hefty price of a file size that can
be a bit larger than unencoded raw data! However, pure 1 channel
grayscale encoding is important for the purpose of storing raw 8 bit
Bayer sensor data from a camera in some usage scenarios and even an
error of 1 unit of 256 is not acceptable, so we’ll stick to this brute
force approach if huffyuv or ljpeg encoding is requested.

-> This provides lossless encoding for 8 bpc with 1, 3 and 4 color
channels.
-> Screen for 64-Bit Matlab on OSX rebuilt and tested.
Screen: Add > 8 bpc video capture support to GStreamer video capture engine.

Well, sort of. The code now honors the ‘bitdepth’ parameter and tries
to switch to 16 bpc video capture and/or recording if a bitdepth > 8
bpc is requested. How well this actually works depends a lot on the
operating system and type of GStreamer installation and set of plugins:
- Video recording > 8 bpc untested and not likely to work at the moment.
- Video capture with camerabin1 has a chance of working with supported
cameras and suitable video capture plugins, but so far only osx tested,
which doesn’t support > 8 bpc at the moment, so this was more a
simulation of 16 bpc gray which looks promising. Tests on Linux and
Windows are pending.
- Video capture with camerabin2 probably can’t achieve > 8 bpc because
camerabin2 requires camerawrapperbinsrc to operate and that plugin has
a hard-coded videocrop filter element in its processing path and
videocrop filter as of GStreamer-0.10 only supports 8 bpc. Things might
be much better with GStreamer-1.0 but for the moment we are still stuck
on the v0.10 series due to other limitations of the 1.0 series.
-> This is more a forward/future looking enhancement, with hopefully
pays off once we port to GStreamer 1.0 in the future.

-> Screen for 64-Bit Matlab on OSX rebuilt and tested.
Screen: Change GStreamer videocapture performance optimizations to "off by default"

Performance optimizations during GStreamer videocapture via setting of
“filter-caps” on the video source were on by default, with opt-out via
‘recordingflags’ 4096 on troublesome cameras. Now we change it to an
opt-in: Only apply optimizations if flag 4096 is present instead of
absent.
-> Potential small performance impact, but higher acceptance for weird
cameras.
-> Screen for Matlab on OSX rebuilt and tested.