Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@IlmarsXd
Copy link

@IlmarsXd IlmarsXd commented Aug 12, 2025

uncut
duration: 12975
date: 1755021910454 // 8/12/2025, 9:05:10 PM

first cut
duration1: 3690
date1: 1755021910454 // 8/12/2025, 9:05:10 PM

second cut
duration2: 5956
date2: 1755021914148 // 8/12/2025, 9:05:14 PM
date ends up being first segment start + first segment length (1755021910454 + 3690)
since we have the full replay to test, can check the real full time: 12975
so the real start date should be first segment start + first segment length + second (cut) segment length,
1755021910454 + 3690 + (12975 - 3690 - 5956)

after fixes:

uncut
duration: 23803
date: 1755029588637 // 8/12/2025, 11:13:08 PM

first cut
duration1: 7876
date1: 1755029588637 // 8/12/2025, 11:13:08 PM

second cut
duration2: 3964
date2: 1755029600242 // 8/12/2025, 11:13:20 PM (includes cut time: 1755029600242 - 1755029588637 = 11605, 11605 - 7876 = 3729 <- trimmed time)

third cut
duration3: 4574
date3: 1755029607866 // 8/12/2025, 11:13:27 PM (1755029607866 - 1755029600242 = 7624, 7624 - 3964 = 3660 <- trimmed time)

@IlmarsXd IlmarsXd marked this pull request as draft August 13, 2025 09:14
@IlmarsXd
Copy link
Author

Realized this solution works for my use case of just needing the correct timestamps at recording time, but would break if any other sort of editing was applied to the replay file produced, would still incorrectly offset it, but in a different way.
(adding a cut keyframe after a split would incorrectly set the start time to the cut end time and then the first part of the replay could be possibly lost)
Feel free to close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant