Screen: Fix Format-7 framerate reporting for dc1394 video capture.

"Fix" it by not querying the cam in Format-7 mode, but just using
the calculated nominal value. All tested fw cams report zero = unsupported,
so nominal fps is used as fallback, except one cam which reports completely
bogus values.

This fix allows to get a more proper recording framerate for video
recording to movie files if Format-7 is selected.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen: Add option to prefer Format-7 capture in dc1394 video capture engine.

A new Screen('SetVideoCaptureParameter', grabbers(i), 'PreferFormat7Modes', 1);
setting allows to tell the engine it should prefer Format-7 capture modes over
Non-Format-7 ones, even those would do for given resolution, framerate and ROI.

Why? Because sometimes a Format-7 mode allows to get the same framerate/resolution
and color precision at a slightly lower firewire bus bandwidth consumption.
This setting is therefore useful if one wants to squeeze out maximum performance
or the maximum number of cameras on a given bus.

Default is old behaviour of auto-selecting the mode and preferring non-Format-7
modes if they will do, as Format-7 modes are only supported by higher end gear.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo.m tests this by capturing video from a
   dual-fw-camera setup at 640x480 pixels resolution at 60 fps, which
   would not be quite possible in non-Format-7 mode due to slightly higher
   bus utilization.
Screen: Add "stop of capture" framecount barrier to dc1394 capture.

We need to make sure that when synchronized stop of capture on
multi-cam synced setups is requested, that all recording threads
dequeue and push the same number of frames from the engine before
terminating, so we don't end up with different final framecounts
in the video files between different cameras.

This adds an implementation which uses the framecount at end of capture
of the master as reference value for all threads to stop.

The target stop count can also get manually queried and set, as
well as the current and possible capture counts.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> Demo updated for testing.
-> Lightly tested with bus sync and seems to work there. More tests tbd.
Screen/libdc1394: Improve multicam synced stop of capture.

Make sure none of the slave threads ever gets ahead of the
master thread in count of captured frames, so once we stop
the master, we can be sure none of the slaves got ahead of
it due to scheduling differences.

-> Screen for 64-Bit Octave on Linux rebuilt and basic tested.
Screen/dc1394: Allow to set 'StopAtFramecount' before capture is started.

We use an intermediate latch variable to allow either changing the limit
while capture is running, as before, or to set the limit at 'StartCapture'.

-> More flexibility, less race conditions.
-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen/dc1394: Allow use of background thread for regular video capture.

recordingflags & 16 can now request use of the background processing
thread even if video recording isn't active. This allows to offload
computations like debayering and color conversion in pure video capture
configurations.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo uses threaded capture atm to test this.
Screen/dc1394: Add video frame timestamping support during recording.

If the 'movieoptions' flag 'UseVFR' is used, then "Variable FrameRate"
recording is enabled: Each video buffer is timestamped with its video
capture timestamp from libdc1394 capture before it gets pushed into
the GStreamer video recording pipeline. The pipeline omits the videorate
converter element which would normally normalize the timestamps to
correspond exactly to the nominal framerate of the recording.

-> The recorded video contains timestamps which are still zero-based,
   as they count time since start of movie, but the individual frame
   timestamps are no longer synthetic, but from the real live video
   capture process, so they should capture potential variability or
   camera sync issues.

-> Regular movie writing via Screen('CreateMovie') always uses
   videorate converter + synthetic timestamps.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo uses 'UseVFR' by default during recording
   to test this.
Backup commit.
Screen/dc1394: Implement dropframes = 0 for multi-threaded video recording.

Push frames into GStreamer pipeline, but use 'tee' element in pipeline +
an appsink to queue frames inside GStreamer, so masterthread can pull
frames out of this appsink.

-> Pipeline serves as internal frame store and will allow GStreamer
   based post-processing in the future.

-> Screen for 64-Bit Octave rebuilt and tested.
Screen/dc1394: Fix crash on 'StopCapture' if framecount < stopAtFramecount

The way stopAtFramecount was updated at 'StopCapture' time wasn't sound.
Fix this, so setting a stopAtFramecount and then calling 'StopCapture'
before that target count is reached doesn't lead to a crash.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen/dc1394: Implement GStreamer dropframes=0 multi-threaded capture.

Now we can (ab)use the GStreamer pipeline and appsink for dropframes=0
implementation if multi-threaded processing in the libdc1394 engine
is requested.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen/dc1394: Cleanup of some status messages and of code formatting.

-> white space cleanup in Common/Screen/PsychMovieWritingSupportGStreamer.c
-> Status message updating wrt. video recording vs. GStreamer video processing.
Screen/dc1394: Only report dropped frames if 'dropframes' is true.

Otherwise it just doesn't make lot of sense as a summary at end of capture.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
VideoMultiCameraCaptureDemo: Add more test code for sync'ed stop of capture.

A keystroke will use the 'StopAtFramecount' setting to schedule logical stop
of capture at current framecount, but then keep the frame fetching+display
loop running until a second keystroke really stops capture.

This allows to test that frame-fetching with effectively stopped background
thread still works, as long as capture is not really stopped via 'StopCapture'.
The latter will release the whole GStreamer pipeline, ergo the ptbvideosink,
ergo all queued frames.

-> Works.
Screen/dc1394: Add GStreamer post processing support to video capture.

The new 'SetVideoCaptureParameter' setting 'SetGStreamerProcessingPipeline=xxx'
allows to define a gst-launch style GStreamer pipeline which can post-process
captured video before it is returned to the userscript by Screen('GetCapturedImage').

The processing only affects returned video, not recorded video, and it only works
with 'dropframes' = 0 setting and multi-threaded capture, ie., when the GStreamer
pipeline is involved.

Data flow is: appsrc -> caps-filter -> xxx post processing -> appsink -> application.
During video recording, a tee element diverts frames before post-processing to the
video encoding/writing pipeline.

-> Screen fore 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo contains a bit of disabled demo code, which shows
   the 'warptv' effect plugin as defined in the variable 'processingString'.

-> This can come handy for post processing tasks like image rotation, gamma correction,
   sharpening/blurring, etc.
Screen/dc1394: Add corrupt frame detection and more IIDC feature controls.

We now use libdc1394_is_frame_corrupt() to detect corrupt frames, we output
warnings if we see some, maintain a queryable counter of them and provide a
summary at end of each capture on non-zero count.

Also add new IIDC feature settings which were so far missing.

-> Screen for 64-Bit Octave rebuilt and tested.
Screen/dc1394: Add many more IIDC settings and functions.

Screen('SetVideoCaptureParameter') supports quite a few more
settings and functions now:

'ResetCamera' and 'ResetBus' to reset a camera or its corresponding
firewire/USB bus.

'PIO' to query or set the up to 32 GPIO pins on a camera.
'Temperature' to control camera temperature.
'WhiteShading' and 'WhiteBalance' for on-camera color correction.
'GetCycleTimer' to query the firewire bus cycle timer + system timestamp to
allow establishing a mapping between bus time and system time.

All remaining scalar IIDC parameters can be set/queried.

'ISOSpeed' to request a specific ISO bus speed.
'1394BModeActive' to enable 1394b mode for speeds of more than 400 MBit/secs.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo has new (commented out) test code for this.
Screen/dc1394: Basler SFF feature support.

Allow optional use of some SFF "SmartFeatureFramework" features of
Basler cameras:

- CRC checks on frames to detect corrupted video frames especially
  reliably. Very time consuming: + 10 msecs for 640x480 images on a
  fast machine.

- Capture timestamps from the camera, computed from firewire bus
  timestamps to tag start of image exposure. Doesn't work with the
  two tested models of Basler cams though - they report a constant
  and totally bogus value! Code audit of our code and libdc1394 and
  comparison with Basler's spec doesn't show any bugs. Mystery...

- Framecounter values from camera. Only workable if the camera allows
  power-cycling by us, so we can reset the counter to a well defined
  zero value at camera open time. One Basler cam allows this, the other
  doesn't allow power-cycle, so this feature causes hard hangs!

- Improved 'GetCycleCounter' query: Now maps count to seconds of bus
  time. The firewire bus has a clock tick of ~24 Mhz so resolves time
  in ~1/24th microseconds. Due to only a 32-Bit counter the timestamps
  wrap around every 128 seconds though, so special remapping and
  wraparound handling is needed to make use of this feature.

- Minor fixes here and there, some refactoring.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
-> VideoMultiCameraCaptureDemo contains demo code, but mostly commented
   out, as only the CRC checking proved to be consistently working on
   tested cameras.
Screen/dc1394: Optimize away GStreamer pipeline if no-recording and recording flags = 4.

If usercode doesn't want to use Screen('GetCapturedImage') ie., recordingflags & 4,
and no video recording is active, then disable GStreamer pipeline feedback path.

Shaves off another few fractions of a msec and some threads.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen/Linux: Detect powered down NVidia GPU's and refrain from using them.

On hybrid-graphics Optimus Laptops with combined Intel + NVidia GPU,
the NVidia card is usually powered down, therefore offline/disconnected
from the bus. As we no longer low-level attach to Intel-GPU's by default
for safety reasons, Screen() would fall back to the disabled NVidia card,
read trash data from its offlined registers and clutter the console with
many useless warnings.

Now we detect if we try to access an offline NVidia card (register reads
return 0xffffffff) and report/handle this properly by detaching from that
card.

-> No low-level access to either the Intel card or NVidia on such a
   setup. Good, because we don't need low-level access as the Intel
   card gets its timestamps from DRI/OML, and this way we avoid
   confusing users with tons of false alarm warnings.

-> Screen for 64-Bit Octave on Linux rebuilt and lightly tested:
   - Confirmed that it still works correctly on non-Optimus.
   - Don't have a Optimus test machine, so i hope it will work as
     expected on such a Optimus setup. Maybe Stephan de la Rosa can
     confirm.