Integrate AVI Video Display into Markable Canvas (renamed issue)

[saulgreenberg]

Add the ability to code .avi files as well as jpgs.

Changes should include

• markers support over a preview frame, as it simplifies coding greatly to avoid special cases, and allows people to mark key frames.
• ability to infer approximate ImageTaken metadata for parity with .jpg handling
• a ‘play’ button that allows the video to be played (which can easily be done by overlaying or popping up a window atop the image).

I also think the user should have the ability to set the preview frame that should be displayed (i.e., so the markers can be used relative to that frame).

[saulgreenberg]

Further thoughts about AVI - lets discuss this if you disagree.

There are two obvious ways to do this:

1. When an AVI is detected, completely replace the image viewer with a special AVI viewer, and have controls modified to do things particular to the AVI. OR
2. When an AVI is detected on initial load, extract and save a frame of it as a JPG in the image set so it is viewable in the image viewer in the normal way. As images are displayed in Timelapse, it looks to see if there is a matching AVI of the same name and enables controls that allow the AVI to be played (ideally in a layer just above the image layer in the canvas but below the markers, so it looks like it is being played in place). Video controls could include one to replace the JPG with a different frame.

In keeping with my original comments, I think 2 is far better than 1 for the following reasons.

• There is almost no special casing with the existing system, as it still acts over the core image. In particular, markers would still be active
• Coding is very simple. The only addition is to create a video player, where the option to play it is triggered by detecting an avi file of the same name when showing that image.
• We don't even have to change the database to store the selected frame if we immediately do a frame grab and replace the corresponding JPG image with that frame grab
• Admittedly, Markers would be in the wrong spot if a person changes the frame, but that is minor compared to having to turn markers on/off (which I think shouldn't be done as it means that users would not be able to click on the image to increment counts). T
• Users can delete videos (saving considerable space) but still have the image to show. Again, trivial to do.

Option 1 is far more difficult to do, and - I think - is simply not needed. It is more inconsistent in the UX as it means that we have to special case 'Videos' vs 'Images', with some things allowed / disallowed for each. It adds complexity about what to do when the video is deleted. I also suspect that once a video is coded, the user will likely not care much about reviewing it again, which also argues for storing and using an image instead.

[saulgreenberg]

A video player is now available that will autoplay videos (in a separate window). The window is activated via the View menu option. However, I consider this temporary - the better solution, as mentioned above, is to integrate video into the main window via the markable canvas.