This is the 2022-07-07 release of Hank's TIK tool

It uses OpenCV in place of direct ffmpeg calls.

Builds with cmake.
Eg.
cmake CMakeLists.txt
make

demo is missing ./es on the tik calls


As distributed: 
uhhh... frame 9 of the output hung?
pg. Make the sequence of ten virtual exposures start 0.5 seconds into the TDCI, representing a sequence of frames at 1 FPS and a shutter angle of 360 degrees:
./tik: writing "mystill0.jpg" as frame 0 (1.000s @ 0.500s) from "kreqc.tik" with quality 4.426
./tik: writing "mystill1.jpg" as frame 1 (1.000s @ 1.500s) from "kreqc.tik" with quality 3.795
./tik: writing "mystill2.jpg" as frame 2 (1.000s @ 2.500s) from "kreqc.tik" with quality 3.542
./tik: writing "mystill3.jpg" as frame 3 (1.000s @ 3.500s) from "kreqc.tik" with quality 3.535
./tik: writing "mystill4.jpg" as frame 4 (1.000s @ 4.500s) from "kreqc.tik" with quality 3.569
./tik: writing "mystill5.jpg" as frame 5 (1.000s @ 5.500s) from "kreqc.tik" with quality 3.526
./tik: writing "mystill6.jpg" as frame 6 (1.000s @ 6.500s) from "kreqc.tik" with quality 3.693
./tik: writing "mystill7.jpg" as frame 7 (1.000s @ 7.500s) from "kreqc.tik" with quality 3.855
./tik: writing "mystill8.jpg" as frame 8 (1.000s @ 8.500s) from "kreqc.tik" with quality 3.526
./tik: Frame 240: 10.042s
-- Hang with a 100% thread for at least 15 minutes because it _runs off the end of the data_ and implodes.

No big deal, trim the length, it does dumb shit if you try to expose off the end. 

OK, next prototype: 
	- Start plumbing pieces from a MLV reader into this tik version
	- Suck pieces in from MLVApp to do the handling
	- Common mlv_structure.h to decode
	- Actually subvert some of MLVApp's reader structure?  It already has a nice decode cache setup
