Screen: GStreamer - Allow frame-skipping / avoidance of texture creation.

The new 'specialFlags' flag setting 0x2 allows to request
Screen('GetMovieImage') to skip actual creation of a PTB texture for a
fetched movie frame. This is useful for 2 tasks:
a) Dropping/Skipping of already decoded video frames for fast seeking
by a few frames.
b) For benchmarking: By disabling all OpenGL code, we can measure the
time overhead of actual waiting for decode to complete.

Screen for 64-Bit Matlab on OSX rebuilt and tested.
Screen - GStreamer: Code formatting cleanup.

Fix indentation in some parts of the code we worked on.
Screen: Add support for low-resolution video decoding to GStreamer playback.

If specialflags1 flags 8 or 16 are set in Screen('Openmovie') and the
video codec supports the 'lowres' property, use it to allow decoding at
half or quarter video resolution.

This totally doesn't work atm. However, restructuring of video codec
setup and some indentation fixes make it worthwhile to commit anyway.
The broken code is left for documenting at least half of the solution
to the problem.

The reason it fails is probably because we would need to set the
property before the first pipeline ready call, so that all pads
negotiate correctly for lower decoder output resolution. But that's
just a hunch. Anyway, the internet says that the lowres decoding
doesn't have any significant benefit on most codecs anyway - except for
Dirac and DV video.

Another Sunday wasted...
Screen: Texture optimizations for GStreamer movie playback.

Use RGB8 instead of RGB as internal format to avoid false format
mismatch warning for YUV textures.

Store YUV texture flag per movie instead of as a gloabl one-time-init
setting, so one can control this on a  movie-by-movie,
session-by-session level.

Use 8-Byte texture pixel_unpack alignment on movies width even number
of pixels per row, instead of 4-Byte alignment. This may or may not
help some OpenGL implementations to squeeze out a bit more performance
during texture creation/update/upload.
Screen/GStreamer: Half finished I420 planar YUV texture support.

This implements the texture upload path, just good enough for basic
performance testing. It is missing the shader-based YUV to RGB
conversion code.
Add test code for GStreamer performance

LoadMovieIntoTexturesDemoOSX knows many new options to benchmark. Not
sure if this is a good idea for a basic demo though.

PlayMoviesDemoOSX - Quick and dirty hacks for performance testing.
Screen for 64-Bit Octave on Linux rebuilt with GStreamer improvements.

For performance testing of GStreamer movie playback improvements.
Screen: Finalize 1st iteration of YUV-I420 support for GStreamer movie playback.

Add support for decoding video into different texture formats. The
target format is no longer selected via cumbersome specialflags1
settings in Screen('Openmovie'), but via a new optional parameter
'pixelFormat' that mirrors the behaviour of the 'pixelDepth' parameter
of the Screen('Openvideocapture') function for the videocapture engine.
This simplifies parameter passing. Currently accepted are values 1-6,
with unsupported values silently remapped to suitable supported values.
We support 1 = Luminance8 -- For 8 bpp grayscale images, 4 for RGBA8 8
bpc, 32 bpp color images, 5 for UYVY 4:2:2 YCrCb textures and 6 for
YUV-I420 planar encoding, with sampling and color space conversion via
fragment shader. The specialflags1 setting 0x1 is still supported for
backwards compatibility and maps to format 5.

Now a proper fragment shader is implemented for format 6 I-420 decode.
It gets auto-generated and attached at texture creation time, then used
by Screen('DrawTexture').

PsychNormalizeTextureOrientation() is now able to convert I420 planar
textures into standard RGBA8 packed pixel textures in upright
orientation, so render-to-texture (use as Offscreen window, use with
Screen('TransformTexture') works for all video texture formats.

Setup of proper texture depths, channel count, upload row byte
alignment etc. now implemented.

Flags for lowres decoding renamed to 4 and 8 for half/quarter
resolution decode. Not sure if we should expose these flags at all,
given how badly the mechanism actually works.

Also some code reformatting.

This is the first really usefully working version. Combined with
multi-threading it provides significant speedups, up to 2.5x.
Screen: Remove lowres support for GStreamer movie playback, add new options.

'lowres' on any tested codec is broken, and according to the internet,
also pretty ineffective, even if it works, so disable it for now.

Use specialflags1 flag 4 to enable visualization of motion vectors
during video decode.
Use specialflags1 flag 8 to enable skipping of B-Frames during video
decode.

Update online help text for Screen('OpenMovie') accordingly.
Screen: Allow immediate texture normalization during GStreamer movie playback.

New optional specialFlags1 flag 16 allows to convert video textures
immediately into upright, normalized format for use as offscreen
windows, for Screen('TransformTexture'), etc, instead of the deferred
"copy-on-write" conversion normally taking place.

This is mostly useful to allow use of user provided custom GLSL shaders
during 'DrawTexture' without the user needing to worry about
I420-sampling and other funny issues.
Screen: Add same optimization to GStreamer videocapture as to GStreamer video playback.

Screen('Openvideocapture') now supports pixeldepth=6 for YUV-I420 video
textures, although it is probably less useful than for video playback,
as most video capture sources probably don't provide this as native
format (at least none i'm aware of).

A recordingflags setting of 2048 requests immediate conversion of video
textures into normalized format for GLSL shading, 'TransformTexture'
and use as offscreen window.

The texture format mismatch warning for YUV-422 textures was fixed as
in video playback.

Formatting fixes.

Help texts updated to point to deprecation of Quicktime for Windows.

Timebase fix: Now report proper video capture timestamps for GStreamer
on OSX as well. Needs the special timebase setup workaround that is no
longer needed on Linux and (probably) Windows. Now capture timestamps
finally make sense.
Modify build file for 32-Bit Windows to use Git tree instead of svn trunk.

makeitOnMPIHDRviaFunky.m adapted for this purpose.
Screen: Rebuild for 32-Bit Matlab on Windows.

To enable GStreamer improvements for testing on Win32.
Screen: Implement optimized GStreamer video playback for greyscale formats.

The new 'pixelformat' settings 7 and 8 will upload Y8 luminance data in
a standard Luminance 8 texture, then use a GLSL shader for colorspace
conversion from Y8 to RGB8 during drawing, just as setting 6 does for
color images in I420 format.

Setting 7 uses the YUV-I420 decode path for color images as setting 6,
but only uploads the Y8 plane, whereas setting 8 uses the Y800 decode
fourcc to request from GStreamer to only create a Y plane. Both
settings use the same Y8 - sampling --> RGBA8 conversion shader in the
end.

In an ideal world, setting 8 should provide extra performance compared
to setting 7, in reality it doesn't, at least with H264 decoding, as
the information about Y800 is apparently not used by the H264 codec to
save itself chroma decoding. Anyway, we provide the setting as an
option, in case future GStreamer versions or different codecs can make
some use of the format for performance optimizations.

This optimization can provide a performance boost of about 10 fps on
typical HD video.

Screen for 64-Bit Matlab on OSX rebuilt.
Screen: GStreamer: Make init path on MS-Windows more robust.

Check for alternative filenames of the GStreamer runtime DLL's on
Windows, so library load and init doesn't file just due to filename
mismatch. Output Windows system error code on failure to give some hint
into the cause of init problems.

Untested on Windows, just code changes so far.
Screen: Use GStreamer SDK from gstreamer.com on OSX for compiling.

Use the SDK from gstreamer.com instead of the 3rd-party provided one
for building on OSX.
It bundles the current GStreamer 0.10.36 instead of the older 0.10.29.
Its runtime provides multi-threaded H264 decoding.

The SDK/Runtime misses x264enc H264 encoding support for movie writing
(but has support for many other codecs, also alternative H264 codecs).
It also misses video capture/recording plugins. For these functions,
the GStreamer 0.10.36 installation built from source via Homebrew is
still needed.

-> Small adaptations.
-> Screen for 64-Bit Matlab on OSX rebuilt & tested.
Rebuild Screen for 64-Bit Octave on Linux.

For testing of current GStreamer optimizations.
makeitOnMPIHDRviaFunky: Try to switch to use of GStreamer-SDK on Windows.

Library- and Includepath adapted for GStreamer-SDK 32-Bit. The Screen.mexw32
file compiles, but at Screen load time results in an invalid MEX file error.

/DELAYLOAD complains about delayload dependencies not getting used/referenced
at all. Something is still wrong.

Babysteps... This is a backup commit.
Revert "makeitOnMPIHDRviaFunky: Try to switch to use of GStreamer-SDK on Windows."

This reverts commit 42baa507122bcfd4f38e22ec413de067b1d43b57.

I declare defeat for now. Also, it doesn't make much sense for us to
use the GStreamer SDK for 32-Bit Windows builds, because the OSSBuilds
SDK we used to use works fine and contains the movie encoders for
movie writing and the videocapture functionality (camerabin, Directshow video source)
we want on Windows.

The only missing feature we want in the OSSBuilds 0.10.7 runtime is the
multi-threaded H264 decoder. We can probably get that from the gstreamer.com
runtime by copying the ffmpeg plugin, as the GStreamer 0.10.x series is supposed
to be ABI compatible.

Situation will be different for 64-Bit Windows builds: Here we don't have
the option of a 64-Bit SDK/Runtime from OSSBuilds and must use the
gstreamer.com SDK with its non-existent video capture support and limited
movie writing support -- and the headache of getting it to link against
our software in the first place.
Screen: Upgrade GStreamer on Windows from 10.6.6. to 10.6.7 OSSBuilds SDK.

Screen.mexw32 for 32-Bit Matlab on Windows rebuilt and tested.

Oh, and btw.: Of course copying the dll from one SDK to the other
didn't work due to unsatisifed other dll dependencies.
So much for ABI stability -- at least on MS-Windows.