Rework the "Align to Video" Feature

[seproDev]

For my kind of work this feature of timing lines to the video is a massive time-saver, but the current implementation makes it nearly useless. The problem with the current implementation is that it is too slow for multiple lines (in my case ~400-800 lines). You need to re-open the dialogue for every line and processing happens in between lines.

This PR adds a queue of lines/position to then process in bulk. After clicking on a position that pixel is added to the queue and the next line is displayed. This allows very quickly going through an entire TS script, since only a single frame needs to be fetched, while all the processing can happen afterwards without any interaction. I also added max extension values, since I don't want to fetch every frame in a 1 hour episode just to confirm that the channel logo doesn't change if one were to click there.

This PR is in draft mode and should not be merged as there are still changes I want to make, but also wanted to get feedback early. I am not very experienced in c++, feedback on my code is appreciated. I'd also like to know if these changes break any existing workflows as for example manually adjusting position/color is no longer possible. I would not use this and see no real use-case for it, but if there is one maybe I can add it again. Things I still plan to add/address:

• [x] Resize to 0 crashes (also in original)
• [x] Progress bar while processing
• [ ] List of queue with option to delete entries
• [ ] Non linear search (Maybe go 20 frames at a first and then binary search? Though this is already kinda done with each jump being 2 frames. Not sure how big the speedup would be)

[TheOneric]

I'd also like to know if these changes break any existing workflows as for example manually adjusting position/color is no longer possible. I would not use this and see no real use-case for it, but if there is one maybe I can add it again.

If you mean, this won't allow using a different colour than the one at the selected position, then here's an explanation of why that's good to have by wangqr from back when I made some minor tweaks to the tool:

wangqr: Usually we know the exact color used in hard subs beforehand. This is because most video author won't change the font color used in their videos. Unlike retriving the color from current frame, manually setting the color will not be affected by video compression artifacts, thus can be used with a smaller tolerance value to be more accurate.

It's good that you brought this up. We may add some improvements here:

• Add a sanity check that the color in current frame is within tolerance of the specified color,
• Add a way (right click?) to allow user pick a position without changing the reference color.

For more info you could ask wangqr or cqjjjzr.

[seproDev]

Oh that's a usecase I didn't consider. Thank you for pointing it out. I've added an option to overwrite the color used.

[seproDev]

Closing, as this functionality should probably be implemented as a script instead. While a position picker API would be nice, the current copy coordinates hack works well enough.

I was about to suggest cherry-picking 700291a, but that crash doesn't happen any more on feature 09, while still happening on feature 08. Didn't see any related commits, but I'll take it.