This changes the display from showing minutes:seconds.tenth of second to the SMPTE timecode format of minutes:seconds.frames. The framerate is rounded so that 29.97 fps displays NTSC non-drop timecode and 23.98 fps displays 24 fps timecode. No attempt at drop frame timecode was made. Although drop frame display a more accurate running time it would be confusing when using the half-shutter to trigger one-frame-at-a-time recording.
I've seen timecode displays with dots and semicolons. In order to stick to the SMPTE standard it would be a colon and it would show the playback time, not the record time. In other words, if FPS override is set to 48 fps this display would show 1 second for the first 48 frames and not 2 seconds for 24 fps playback or whatever it would be for 29.97, 25, 59.98, etc. Obviously that would really complicate things.
The 2 seconds probably comes from "1 second saved" and "1 second in the pre-recording buffer", as in the initial implementation, the counter showed how much we have pre-buffered. Maybe it's best to split the two?
I'm getting a little more familiar with how this works. So the behavior of the counter might need to change depending on which mode is set. I was working under the assumption that we need to track the number of frames that are being saved but in other cases it might be preferable for the counter to show the number of frames (or seconds) that are in the buffer but haven't been written to the card yet.
I'm using frame_count-2 to get the counter to start at zero but left it at frame_count-1 for the ffmpeg time unit syntax counter. Do you think there should be a counter for number of frames in the buffer and a separate counter for the frames written to the card?
BTW--I'm aware that I might have gone overboard renaming fps to fps_x1000 and adding the fps_rounded variable but I wanted to make sure that I knew when the fps was represented as 23976 and when it was rounded off to 24.
It is getting late here and I'm a bit in over my head to create a special display for pre-buffered frames. I wanted to make sure that every time a frame is saved, the counter increments while the time displayed remains (somewhat) accurate.
Still not sure about how to display the pre-buffered frames but I renamed the fps variables and added a menu item to choose between the standard time display, timecode display and frame count display. Switch over to the standard time display while recording and made the standard MM:SS.1/10sec. the default to avoid too much disruption with this pull request.
Moved the Counter display into the Advanced menu. Now everything works as before but the option to display in MM:SS.FF or just frames is available for those users who want to experiment with shooting one-frame-at-a-time and keeping track of the number of frames that are being recorded.