Fix snapping audio times to current video position

[arch1t3cht]

Lots of text incoming, since timestamp wrangling is hell and I want to write down my reasoning before I inevitably forget it again in two weeks.

Before commit 5d4973a, snapping an audio line's end time to the "current video position" indicator line would reliably make the line end on the frame before the current video frame (i.e. make the current video frame be the first frame where the selected line is not visible any more).

Commit 5d4973a broke this, making the behavior of snapping audio times to the "current video position" inconsistent.

The commit in question is definitely not fully correct, ultimately just because the entire concept of implicitly converting millisecond timestamps to centisecond timestamps is flawed in and of itself, and bound to always fail in sufficiently crazy edge cases. Fixing the timestamp conversion properly would entail either working with centisecond timestamps from the beginning, or somehow making the process of converting timestamps aware of the context the timestamps are from (e.g. "coming from some frame timestamp").

However, this specific issue was only exposed by this commit, and not solely caused by it. Its root cause was just that the "current video position" marker on the audio display would mark the exact time of the current video frame, rather than the ideal start/end time for a line to start/end at that video frame. This is why only snapping to the "current video position" broke while snapping to keyframes worked fine. It's quite possible that snapping to the "current video frame" marker was just never thought of as a use case.

So, for now, #421 can just be fixed by positioning the "current video position" marker in the middle of the frame rather than at the frame's exact start, and
5d4973a can be untangled at some later time.

Fixes #421.

---

Still need to decide how to handle the fact that keyframe markers and current frame markers may now overlap.

[petzku]

First: This new snapping behavior itself is much better, thank you.

Still need to decide how to handle the fact that keyframe markers and current frame markers may now overlap.

Personally, I'm not 100% sure if this would really even be a problem, though I would certainly prioritize the keyframe marker. (It is generally easy to guess where the video playhead "should be", though I don't even see it being all too relevant in this case.) But, if we want to avoid it (reasonable), a 1px shift seems most logical to me (though it might not still be too easy to distinguish two adjacent vertical lines like that).

That said, I have slight personal preference to, if possible, keeping the video-playhead cursor visually positioned "on" the frame timestamp. However, I realize this is purely based on opinion, and is not even clearly always "desirable" (just as, to me, it is more "helpful" to see the video playhead indicator slightly offset from properly-frame-snapped times, it might be more confusing to someone else as to why lines are not snapped "correctly onto" the indicator). Most realistically, this is just not feasible.

Visual clarification of above paragraph

To make clear what I mean, I have grown used to recognizing timing like this (where the line start marker is directly on the playhead marker) as "bad":

and timing like this (where the line marker is slightly right of the line start time) as "good":

Meanwhile, with my suggestion, someone snapping a line's end time to the cursor would see this, and might be very understandably confused:

[petzku]

Summarizing some conversation on Discord for posterity:

Hence, we use the following middle-ground solution:

• Keep drawing the "current video position" marker at the exact start
  time of video frames
• Do not allow snapping to the exact time of the "current video
  position" marker. Instead, allow either snapping to the middle of the
  previous frame, or the middle of the current frame.
• To make this behavior understandable for the user, draw a
  semi-transparent rectangle behind the "current video position" marker
  indicating the duration of the previous and current video frame.

I feel like this is otherwise a good solution, but the “meaning” of the rectangle is not intuitively clear. I at first imagined it was supposed to show the “frame-middle” boundaries that lines would snap to (i.e. the edges of the rectangle would be the “snap targets”), but that is not the intent.
However, as the element looks like it should be just one Thing, it is easy to assume it is supposed to represent one frame, not two. This might be best remedied by making the two halves different colors (or otherwise differentiating them). The most logical idea might be to slightly dim the “previous frame” rectangle (perhaps around halfway between the “current frame” and the background color).

It's quite possible that snapping to the "current video frame" marker was just never thought of as a use case.

Notably, while this is indeed quite possible, I see myself using this snapping a fair bit; for example, when trying to snap a line’s end time to a scene change that isn’t recognized as a keyframe.
Currently (to my knowledge), the best/fastest way involves scrubbing the audio display using MMB to find the approximate position, frame-stepping to find the exact frame the scene changes (typically, stepping forwards until the scene changes; repeatedly stepping backwards tends to be much slower), then stepping one frame back (into the previous scene), and using ctrl-4 (time/snap/end-video) to set the line’s end time to that frame.
This change removes the need for the final back-step, and more importantly, ctrl-4, which is rather inconvenient to press—especially so if one uses the arrow keys to frame-step. (Also, potentially allows for an entirely mouse-only approach; though it can be hard to be frame-accurate with MMB scrubbing, depending on one’s horizontal zoom setting.)