Fix video synchronization for Autonomous periods other than 15 seconds.#489
Fix video synchronization for Autonomous periods other than 15 seconds.#489blaze-developer wants to merge 3 commits intoMechanical-Advantage:mainfrom
Conversation
|
Is there a reason why the system searches for specifically the 0:12 mark? If it instead searched for, say, 0:03 perhaps the 600 ms error could be mitigated. |
|
Probably just because it was three seconds after auto began. I'll try to see if using a lower number could minimize it. |
|
Probably just because it was three seconds after auto began. I'll try to see if using a lower number could minimize it |
|
Changed the behavior to search for smaller numbers, and it seems to be synced up nicely! :) |
|
Based on testing with a few of our team's logs, searching for smaller numbers saves about ~100 ms (before it was 200-300 ms error, after it's consistently under 200 ms). |
This PR attempts to solve the problem with video synchronization caused by assuming that Autonomous periods will always be 15 seconds long (#487 ), finding the frame which is 3 seconds in to the auto, (when the countdown reaches 12,) and offsetting that to find the beginning of Autonomous.
The first obvious solution is probably just checking if the log is from 2026, and then changing the amount you offset by. However this will have to continue to be updated for every season that has a different length auto mode. Aiming for broad applicability from season to season, this changes the synchronization to add 12 seconds rather than subtracting 3, and to synchronize based on the end of auto rather than the beginning. This should work always because since we are finding frames from the match timer, the number of seconds displayed will always be the number of seconds left in Autonomous.
After testing, It gets mostly close, however it is ~600 milliseconds off with the log files I tried. This is either an error on my part, or inherent error with using FPS building up over a longer period of time, A potential fix being detecting a smaller number, and shifting by less frames, but I figured that someone else might have some insight.