Screen for 32-Bit Octave on Linux rebuilt and tested.

Checked new kms-pageflip workaround code against Linux 3.15.10.
Screen/Linux: Add test code for NVidia hw vblank counters.

-> Screen for 32-Bit Octave on Linux rebuilt.
-> hw-vblank counters seem to work as expected on NV-d0 display engines.
Screen for 64-Bit Octave on Linux rebuilt.

-> Hw vblank counters work on NV-50 display engine as expected.

-> Good to go for all NV50+ cards afaics :)
GStreamer: Prepare GStreamer-1.4 switch.

Add old GStreamer-0.10 support code in new files
PsychXXXSupportGStreamer010.c, use the PsychXXXSupportGStreamer.c files
for the new GStreamer-1.4+ support code instead.

#define PSYCH_USE_LEGACY_GSTREAMER will enable compilation of the old
0.10 support files, lack of the #define will instead the new 1.4+
support files.

We will unconditionally use the GStreamer-1.4+ support in the future on
OSX and Windows, and for all Linux distributions (late 2014). It’s not
yet decided for older Linux distros if we will provide back ports of
1.4, or if we will continue to build 0.10.x versions for those old
distros.

-> New backup files for 0.10.
-> Conditional compile defines.
-> Xcode project gets the legacy files added for code browsing.
GStreamer-0.10: Replace deprecated functions.

Compile with GST_DISABLE_DEPRECATED showed use of two deprecated
functions. Replaced by good ones and verified stuff still works.

Make makefile be able to build old and new GStreamer backends.
GStreamer-1.4: Make playback engine functional.

Playback engine works, all tests i could do quickly seem to work.

- Playback forward/reverse/different speeds, start/stop.
- Seeking in both directions.
- Pixelformats 3,4,5,6,7,8 [1/2 don’t work with my movies].
- Multi-Threaded video decoding on supported codecs.
- Various different movies, also network streaming.
- Gapless playback variant 1 and 2.
- LoadMovieIntoTextures.
- Looped playback.
- Some bugs are automagically gone.

-> Screen for 64-Bit Octave on OSX rebuilt and tested.
-> Vidcapengine compile-time disabled, as it is tbd.
-> Step 1, we can have so much fun…
GStreamer-1.4: Make video capture and video recording mostly work.

As tested on OSX with internal iSight and external Logitech USB Webcam,
video capture and recording mostly works now.

-> Missing piece: video capture device enumeration via GstDeviceMonitor.
-> A-V Sync is horrible on OSX so far.
-> Other than that, works pretty well.
-> VideoRecordingDemo.m adapted to new caps format x-raw-rgb —> x-raw,
format=RGBA etc.
-> Pure recording now uses an appsink with 1 buffer capacity +
drop-frame instead of a fakesink.
-> All codec setup, caps etc. needed to be adjusted.
GStreamer-1.4: Make movie writing work - Part I

The obviously correct stuff. This beast doesn’t want to work at all so
far.
GStreamer-1.4: Make movie writing partially work.

Video writing works, Video+Sound doesn’t work yet.
GStreamer-1.4: Make audio track writing work.

Now both pure video writing and video + audio writing works.

Needed to timestamp the buffers manually as well.

-> ImagingStereoDemo.m start with 200 Hz instead of 100 Hz so the first
second of sound can be heard by half-deaf people like myself.
GStreamer-1.4: Cleanups + bits of HDR support.

Cleanup dead code, beautify etc. Improve error handling a bit. Add
support for the Schroedinger codec ‘schroenc’ which can encode 16 bpc
YUV as Dirac video stream and store in a qtmux or matroskamux Quicktime
or Matroska container at up to 16 bpc. Add new pixelFormats 9 and 10 to
playback engine to allow decoding 16 bit grayscale and 16 bpc ARGB64 to
16 bpc luminance or RGBA float textures.

So far the theory. In practice encoding seems to work with
Schroedinger. However trying to playback such high bit depth video
crashes the app by triggering an assertion + abort() inside
libschroedinger. Same happens with GStreamer command line tools, so not
a PTB bug. I don’t have any other suitable video players for testing
the high bit depth stream. VLC decodes it without problems, but doesn’t
display anything.

Anyway, the groundwork is laid out.

-> Screen for 64-Bit Octave on OSX rebuilt and tested.
-> ImagingStereoDemo.m contains a new example line for Schroedinger
encoding.
GStreamer-legacy: Cleanup wrong prototype def.

In case we’d ever compile without GStreamer support, we’d have gotten
compile failure.
GStreamer-1.4: Add DeviceProvider based video capture device enumeration.

If GStreamer version is >= 1.4.0, build with support for
GstDeviceProvider and GstDeviceMonitor and use it to dynamically
enumerate video sources which support this. Such source plugins also
store a GstDevice* handle for each detected capture device and this is
used to instantiate a video capture GstElement on request of the
caller, instead of using indirect setting of device selection
properties like “device-index” or “device-name”. The method with the
unique handle is more robust and universally functional as it doesn’t
need dedicated property probing and setting code anymore, good for the
future.

If a source plugin doesn’t support this method, or if built on a
pre-1.4.0 GStreamer, use brute-force fallback code, which will actively
poke some plugins for devices (dc1394src atm.) or just hard-code a
certain amount of devices in the most stupid possible way. This
fallback is unaltered from the 0.10 legacy implementation. The
difference is that it will now apply to almost all video plugins, as
the old property probe interface doesn’t exist anymore.

Current status, as of GStreamer 1.4.0 August 2014:

- Intelligent device provider enumeration supported on Linux with
v4l2src Video4Linux2 video capture plugin.

- Dumb method used for all other plugins on Linux and all plugins on
OSX and Windows, which means all device detection is brute-forced on
OSX and Windows.

- On Windows, only ksvideosrc is ported to GStreamer 1.x, dshowvideosrc
isn’t ported yet. Problematic, given how badly kernel streaming worked,
whereas DShow was ok’ish.

On OSX we have the crappy osxvideosrc which uses QTKit, which has been
deprecated by the idiots of Cupertino since OSX 10.9. Then we have the
new avfvideosrc which uses the new and shiny AVFoundation, the current
“greatest bestest, most advanced way of doing video capture” on OSX -
until maybe next year the idiots will come up with yet another greatest
and bestest, of course, to keep life interesting…
miovideosrc is not part of GStreamer 1.4.0, apparently because it used
Apple private Frameworks, so was probably not a future proof way of
doing things. The plugin still exists in the Git source tree, but in a
non-public branch.

Other changes:
- Always add a videotestsrc to device list, so we always have at least
the synthetic test images for testing on machines without actual
connected cameras.
- Change probe order on OSX: AVFoundation first, so it enumerates as
default capture device with deviceIndex 0. Why? Because AVFoundation
capture works marginally better than QTKit capture on OSX 10.9, at
least as far as a quick test seems to indicate.

-> This code is so far only lightly tested on OSX 10.9 with internal
iSight. The dynamic device provider/monitor enumeration compiles
cleanly, executes without crash, but does essentially nothing, so is
not really tested, as on OSX none of the plugin supports device
providers/monitors so far. This will need to get thoroughly tested on
Linux + Video4Linux2.
GStreamer: Switch between new and legacy based on version check.

Use version check macro to decide if to use the new backend (version >=
1.0.0) or the old legacy backend (version < 1.0.0)
-> No need for extra -DPTB_USE_LEGACY_GSTREAMER anymore.
-> Compilation dependent on SDK header files and their version.
Screen for 64-Bit Octave and Matlab on OSX rebuilt and tested.

This enables the 1st working ok iteration of the new GStreamer-1.4.0
based multi-media backend.
-> osxmakeit makefile for 64-Bit Matlab switched to GStreamer-1.x
-> VideoRecordingDemo.m needs an additional wait after
‘OpenVideoCapture’ to avoid jerky recording immediately at first
iteration after startup of Octave/Matlab.

- Remaining problem: Videocapture with reqdepth 6 (I-420 + shader)
crashes sometimes after capture of first frame. GStreamer bug or PTB
bug?
- Remaining problem: Switching to a non-default video capture
resolution via roi = [0 0 width height] doesn’t work yet, although
capturing at full default resolution with an arbitrary roi [left top
right bottom] works just fine.

-> Good enough baseline for Windows porting and Linux porting.
Screen/Windows: Switch compile to GStreamer-1.0, fix build failure.

Switch to build against GStreamer-1.4.0.
Fix a small compile failure.
Screen: Fix all compiler warnings when building on Windows.
Screen: Fix delay loading on Windows with GStreamer-1.4

Need to replace all instances of
GST_VALUE_HOLDS_FRACTION/LIST/FRACTION_RANGE by G_VALUE_HOLDS(xxxx,
get_fraction_range_get_type()) etc. and GST_TYPE_FRACTION by
gst_fraction_get_type()

Why? Using the macros will inline some stuff from
libgstreamer-1.0-0.dll which will prevent delay-loading of said DLL and
thereby prevent delay loading of GStreamer as a whole. Using the
gst_xxxx_get_type() functions adds just enough indirection to prevent
the delay-load problems.

-> Delay loading works. Screen() works on a system without
GStreamer-1.4.0 or later installed, as long as one doesn’t use
GStreamer based functionality. If the movie playback/writing or Video
capture/recording functions are used, Screen() will abort with a
helpful message, directing the user to install GStreamer-1.4.0 or later.

-> First delay-loadable Screen.mexw64 for 64-Bit Matlab on Windows
included. Not yet actually tested with new GStreamer backend, but it
compiles, loads, works with basic functions.
VideoRecordingDemo: Switch to directsoundsrc on Windows.

dshowaudiosrc doesn’t (yet? ever?) exist in GStreamer-1.4, but
directsoundsrc does exist.
Adapt VideoDVCamCaptureDemo to GStreamer-1.x