Add higher video compression modes

[mattem86]

For now, you have one small and big file setting. I understand that the CPU is already very busy on online detection, so the file compression should not be too eager. But the files get very big even on small setting, if you record several minutes.
For the users who do offline detection it would be nice to have some more modes available, for example h265 compression.
I can easily shrink the file size with "Handbrake" from 1,5 gb to 50 mb in h264 (!) and with -q 20 setting.

[mkassner]

@mattem86 yes, it would be great to use h264 instead of MPEG-4 however we found this uses even more CPU. I recommend using non compression during recording then then transcoding using ffmepg/handbreak afterwards if you workflow permits it.

[bpinsard]

FYI: I have been quickly implementing libx265 in our pupil fork to better compress the grayscale image from a high-speed camera. Libx265 provides different presets and tuning parameters for fast compression, and I think ffmpeg can run it on GPU for color frames (not tested).
https://github.com/courtois-neuromod/pupil/blob/gigevision_rebase/pupil_src/shared_modules/av_writer.py#L291
It is true that CPU usage is quite high with that compression, but is seems to be done in a separate thread and not to block the main loop of the eye process (tested and profiled on recent laptop and desktop).

To decrease detection CPU usage and aiming to do offline processing I turn off the 3d detector, and implemented subsampling of the frame (eg 1 every x frame) when running online detection with the 2d detector ( https://github.com/courtois-neuromod/pupil/blob/online_detect_subsample/pupil_src/shared_modules/pupil_detector_plugins/detector_2d_plugin.py ).

I will try to make clean PRs at some points.

[mattem86]

Great work, thank you for keeping me up to date!

Since the Detectors are using one core each, maybe you can delegate the compression on quad/hexa/octa-core CPUs on two other cores? Or even involve the GPU? Hardware-encoders in CPUs are very powerful and highly optimized (as you may know for sure) soo maybe there would be not much of an overhead. At least on newer CPUs. I understand Pupil Labs wants to support the lowest specs as possible :)

An alternative approach would be to use the plugin system where you can grab the raw jpegs and process them. Then there would be no need to pull this into the main repo for now. The plugin system evolved very powerful... we also use this to record both the world and the hmd video stream (which is not officially supported, yet), while running from binaries.

[papr]

@bpinsard Feel free to link your fork in https://github.com/pupil-labs/pupil-community if you have not yet. This should help with discovery for other people.