-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add implementation of to_nearest_timecode #1717
Add implementation of to_nearest_timecode #1717
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1717 +/- ##
==========================================
- Coverage 79.95% 79.89% -0.06%
==========================================
Files 197 197
Lines 21879 21900 +21
Branches 4342 4351 +9
==========================================
+ Hits 17494 17498 +4
- Misses 2252 2269 +17
Partials 2133 2133
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm; if you wouldn't mind doing the DCO steps indicated in the CI, that should clear up our ability to merge.
…version of timecode from a rate using the closest valid time code rate. Signed-off-by: Anton Marini <[email protected]>
Signed-off-by: Anton Marini <[email protected]>
Signed-off-by: Anton Marini <[email protected]>
810b27b
to
1207631
Compare
Thanks for your patience. DCO Sign off passed. I'll try to keep that in mind in the future! |
Add implementation of
to_nearest_timecode
which makes approximate conversion of timecode from a rate using the closest valid time code rate.This is intended to fix various downstream adaptor hiccups where source material might be variable frame rate, or close but not quite an exact SMPTE timecode.
Link the Issue(s) this Pull Request is related to.
#830
Summarize your change.
This PR does not directly fix the FCP_XML adaptor, but rather isolates changes to OTIO core and exposes a
to_nearest_timecode
with the same method signature asto_timecode
.This is intended to act as a entry point for changes to other adaptors if deemed a valid approach
Reference associated tests.
No new tests just yet.