Skip to content
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

Create Java Bindings #753

Closed

Conversation

KarthikRIyer
Copy link
Contributor

@KarthikRIyer KarthikRIyer commented Jul 9, 2020

#694

  • Initialized java bindings.
  • Partially implemented RationalTime.

Memory management needs some discussion. One way would be to delete the object in the finalize method of the class and the other would be to provide the method to delete the object and let the end user handle everything.

I'm using finalize to delete, for now.

finalize is deprecated as of Java 9. It can cause problems as mentioned here:

One problem is that, because the JVM only controls memory and resources within the Java heap, it can’t take into account any resources allocated in the native layer when determining which Java objects it needs to garbage-collect: our Java objects will seem smaller than they effectively are. So it might not finalize our objects quickly enough to prevent memory pressure.

A second problem is that we can’t guarantee which thread the finalize method will be called from. It’s quite important that our C++ object is deleted from the same thread that allocated it.

and here.

@KarthikRIyer
Copy link
Contributor Author

@meshula @jminor @ssteinbach @reinecke

While going through opentime tests I found that:

https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/992b3c21d851b4ba815bf70fcae6ab9de3e174b0/tests/test_opentime.py#L362-L364

Here, while testing for faulty timecode formatting, we're actually getting a NON_DROPFRAME_RATE error where we should be testing for INVALID_TIMECODE_STRING.

@meshula
Copy link
Collaborator

meshula commented Jul 10, 2020

Does anyone recall why 01:00:13;23 is meant to raise a ValueError for 24fps? The semi-colon indicates non-drop-field-2, so roughly speaking NON_DROPFRAME_RATE is mostly correct, and 23 is valid frame at 24.

@KarthikRIyer
Copy link
Contributor Author

KarthikRIyer commented Jul 10, 2020

so roughly speaking NON_DROPFRAME_RATE is mostly correct,

My confusion here was because of the test title. It say's faulty formatted. That's why I thought we needed to check for INVALID_TIMECODE_STRING.

The semi-colon indicates non-drop-field-2

What does this mean? Why do we drop frames? And what is the difference between timestring and timecode? Does timecode include frames whereas timestring uses seconds and decimal point for something less than a second?

@KarthikRIyer
Copy link
Contributor Author

RationalTime is done and it's tests are half done. Could someone take a quick glance and make suggestions if any? So that I can take care of them for rest of the bindings.

@apetrynet
Copy link
Contributor

I believe it's convention to use ";" semi-colon as an indicator of a drop-frame frame rate. So 24 fps should not have semi-colon while 23.976 should.

From wikipedia

While non-drop timecode is displayed with colons separating the digit pairs—"HH:MM:SS:FF"—drop-frame is usually represented with a semicolon (;) or period (.) as the divider between all the digit pairs—"HH;MM;SS;FF", "HH.MM.SS.FF"—or just between the seconds and frames—"HH:MM:SS;FF" or "HH:MM:SS.FF".[c] Drop-frame timecode is typically abbreviated as DF and non-drop as NDF.

@meshula
Copy link
Collaborator

meshula commented Jul 10, 2020

@apetrynet That's true about the semicolon, but the encoding wouldn't be 23.976. The SMPTE spec doesn't allow for partial frames -

 <xs:restriction base="xs:string">
  <xs:pattern value="[0-2][0-9](:|/|;|,|\.|\+|\-)[0-5][0-9](:|/|;|,|\.|\+|\-)[0-5][0-
                   9](:|/|;|,|\.|\+|\-)[0-5][0-9]" />
 </xs:restriction>
 </xs:simpleType>

Normally the spec is here - but ieee.org seems non-responsive at the moment. https://ieeexplore.ieee.org/document/9097510

@reinecke
Copy link
Collaborator

reinecke commented Jul 11, 2020

Summary

01:00:13;23 would be a drop-frame timecode, drop-frame timecodes only apply for NTSC rates (24000/1001, 30000/1001, 60000/1001, etc.).
Any framerate, NTSC or whole, is a valid to use non-drop frame timecode. Non-NTSC rates should not use drop-frame (this could use a citation, I recall seeing a SMPTE document actually verifying this but my memory could be flawed).

EDIT:
It is not valid to infer a timecode is drop-frame because the media rate is an NTSC rate. In other words, non-drop timecode can be used for all media rates, drop-frame timecode cannot be used for all media rates.

More background

What is fps?

FPS represents a sampling or playback rate for video. It is the number of video samples (frames) collected for every second of wall clock time. The baseline frame rate cinema playback has settled on is 24fps. PAL television (as used in the UK) is 25fps.

NTSC Rates

Television in the US was originally 30fps, but due to the method in which color information was added in the middle 20th century, the rate had to be slowed to 30000/1001 fps (commonly referred to as 29.97fps). There are other NTSC rates that exist and are similarly slowed down, the most common are:

  • 23.976 (technically 24000/1001)
  • 59.94 (technically 60000/1001)

What is timecode?

Timecode is a scheme for labeling video frames. It uses a numbering system that closely relates to time but can deviate from time in certain case. It is a system based on discrete time (based on whole frame increments) as opposed to continuous time (can represent an "infinite" precision of time).

Timecode is structured as HOURS:MINUTES:SECONDS:FRAMES. There are 60 minutes per hour, 60 seconds per minute, and number of frames per second depends on the timecode rate. If I recall correctly, in general HOURS "rolls over" to zero after 23 (there is genrally no hour 24).

Note that all fields in a regular video timecode are integers. Timecode is incremented by increasing the FRAME counter for each video frame being labeled. There is no such thing as a fractional frame number.

An aside: there are some corner cases about interlacing and "audio timecode" that can encode something like partial frames, but those are not considered in common use cases or OpenTimelineIO's support.

How does frame rate relate to timecode?

in timecode, frame rate is used to derive how many frames are enumerated before the FRAMES field is "rolled over" and the SECONDS field is advanced. Since there are no fractional frames in timecode, you typically use the ceil of the media rate as the timecode rate. It is because of this that the timecode rate relates to the media rate but it may be different. For example: 24fps media has a timecode rate of 24, 23.976fps media has a timecode rate of 24.

Let's look at that again: 23.976fps has a timecode rate of 24.

So this means, when you enumerate the 24th frame of a 23.976 fps video, your timecode will read 00:00:01:00 (one second), but since you're playing back at 23.976 fps, it took ~1.001 seconds to play back those frames. What this means, is that the HOURS, MINUTES, and SECONDS fields in timecode may not match what a clock would read if you timed the playback of those frames. Over one second, that drift is not significant. Over one hour that error accumulates to about 4 seconds, over a day it's about 1 minute 26 seconds.

Drop-frame timecode is a system of skipping certain timecodes in the labeling scheme to bring the timecode's hours, minutes, and seconds back into sync with "Wall clock" time. This was mostly developed to make timecode time match real time so people scheduling could use timecode runtime to slot out their broadcast schedules. It is kind of the same idea but inverse of how we add a date to leap-years to keep the calendar in sync with the earth's orbit.

Because drop-frame timecode is just altering the labeling scheme to make NTSC rates match wall-clock time, it does not make sense to use it with non-NTSC timecode rates. Because some people prefer to have a consistent labeling scheme for their frames, it is allowed (and very common) to use non-drop frame timecode with NTSC rates. In this cases it is just accepted that the hours, minutes, and seconds will drift from wall-clock time.

To re-cap:

  • Drop-frame timecode is only allowed for NTSC frame rates
  • Non-drop is allowed for ALL frame rates

@KarthikRIyer
Copy link
Contributor Author

Thanks for the detailed but simple explanation @reinecke ! That helped.

@apetrynet
Copy link
Contributor

@meshula. True, I should have been more specific. I meant the frame rate 23.976.
Really nice summary @reinecke !

@meshula
Copy link
Collaborator

meshula commented Jul 11, 2020

Now I understand why the error is "NON_DROPFRAME_RATE". My rule of thumb is that if a line of code requires a lot of careful explanation when someone new comes across it, it deserves formal documentation at the call site. So @KarthikRIyer I think a couple of sentences that explain to the next person what the test is for are in order. @reinecke Since you've gone to the trouble of carefully explaining an important aspect of the system could I trouble you to pretty please transplant your excellent essay into our formal docs? This should be an appendix on readthedocs...!

@reinecke
Copy link
Collaborator

@meshula I couldn't agree more. This is an area where it's complex for a lot of very obscure reasons. I'll look into creating a documentation section that addresses timecode use in OTIO.

@KarthikRIyer
Copy link
Contributor Author

Will do @meshula

@codecov-commenter
Copy link

codecov-commenter commented Jul 12, 2020

Codecov Report

Merging #753 into master will increase coverage by 0.76%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #753      +/-   ##
==========================================
+ Coverage   83.21%   83.98%   +0.76%     
==========================================
  Files          74       74              
  Lines        2884     3122     +238     
==========================================
+ Hits         2400     2622     +222     
- Misses        484      500      +16     
Flag Coverage Δ
#py27 83.25% <ø> (+0.12%) ⬆️
#py36 83.32% <ø> (+0.12%) ⬆️
#py37 83.32% <ø> (+0.12%) ⬆️
#unittests 84.12% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...pentimelineio-bindings/otio_errorStatusHandler.cpp 62.26% <0.00%> (-6.97%) ⬇️
...lineio/opentime-bindings/opentime_rationalTime.cpp 97.43% <0.00%> (-1.08%) ⬇️
src/opentimelineio/serializableObject.cpp 57.97% <0.00%> (-0.86%) ⬇️
src/opentime/timeRange.h 100.00% <0.00%> (ø)
src/opentime/errorStatus.h 100.00% <0.00%> (ø)
src/opentimelineio/gap.cpp 100.00% <0.00%> (ø)
src/opentimelineio/effect.cpp 100.00% <0.00%> (ø)
src/opentimelineio/marker.cpp 100.00% <0.00%> (ø)
src/opentimelineio/timeline.cpp 100.00% <0.00%> (ø)
src/opentimelineio/errorStatus.h 100.00% <0.00%> (ø)
... and 34 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 992b3c2...5b4c5f7. Read the comment docs.

@KarthikRIyer
Copy link
Contributor Author

Opentime done! Moving on to OTIO.

@KarthikRIyer
Copy link
Contributor Author

@margant Now all platform native libs are included in the JAR and everything builds and runs properly. Please take a look. I've commented out the macOS portions because I don't have a mac.

The process to publish would be:

  • gradle build
  • gradle nativeUpload -Dbintray.user=<insert bintray username> -Dbintray.key=<insert API key>
  • gradle nativeDownload This will fail if any of the native libs are not present on bintray. So we need to execute gradle nativeUpload on all platforms before we download stuff for release.
  • ./gradlew bintrayUpload -Dbintray.user=<insert bintray username> -Dbintray.key=<insert API key>

Does this look ok?

@reinecke did you get a chance to try building on a different mac?

@reinecke
Copy link
Collaborator

reinecke commented Sep 4, 2020

@KarthikRIyer Just tried a build again on my home machine:

[ 57%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Any.cpp.o
/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/src/main/cpp/io_opentimeline_opentimelineio_Any.cpp:44:20: error: call to 'create_safely_typed_any' is ambiguous
    any anyValue = create_safely_typed_any(std::move(longParam));
                   ^~~~~~~~~~~~~~~~~~~~~~~
/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/../opentimelineio/safely_typed_any.h:27:5: note: candidate function
any create_safely_typed_any(bool&&);
    ^
/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/../opentimelineio/safely_typed_any.h:28:5: note: candidate function
any create_safely_typed_any(int&&);
    ^
/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/../opentimelineio/safely_typed_any.h:29:5: note: candidate function
any create_safely_typed_any(int64_t&&);
    ^
/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/../opentimelineio/safely_typed_any.h:30:5: note: candidate function
any create_safely_typed_any(double&&);
    ^
1 error generated.
make[2]: *** [src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Any.cpp.o] Error 1
make[1]: *** [src/main/cpp/CMakeFiles/jotio-1.0.0.dir/all] Error 2
make: *** [all] Error 2

> Task :compileJNI FAILED

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/build.gradle' line: 72

* What went wrong:
Execution failed for task ':compileJNI'.
> Process 'command 'sh'' finished with non-zero exit value 2

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 32s
2 actionable tasks: 2 executed

@KarthikRIyer
Copy link
Contributor Author

Why is it ambiguous between these four types? :/

@KarthikRIyer
Copy link
Contributor Author

@reinecke could you please try to build once more after explicitly casting longParam to int64_t.

@reinecke
Copy link
Collaborator

reinecke commented Sep 4, 2020

@KarthikRIyer That looks like it did it!

[eric@Slabby:~/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio]$ ./gradlew build

> Task :compileJNI
true
-- Updating git submodules to make sure they are up to date
-- pybind11 v2.3.dev0
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/eric/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio/build/natives
[  3%] Built target opentime
[ 45%] Built target opentimelineio
Scanning dependencies of target jotio-1.0.0
[ 46%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Any.cpp.o
[ 48%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_AnyDictionary.cpp.o
[ 49%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_AnyDictionary_Iterator.cpp.o
[ 50%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_AnyVector.cpp.o
[ 51%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_AnyVector_Iterator.cpp.o
[ 53%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_ErrorStatus.cpp.o
[ 54%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_SerializableObject.cpp.o
[ 55%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_SerializableObjectWithMetadata.cpp.o
[ 57%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_SerializableCollection.cpp.o
[ 58%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Marker.cpp.o
[ 59%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_MediaReference.cpp.o
[ 61%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_MissingReference.cpp.o
[ 62%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_ExternalReference.cpp.o
[ 63%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_GeneratorReference.cpp.o
[ 64%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Effect.cpp.o
[ 66%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_TimeEffect.cpp.o
[ 67%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_LinearTimeWarp.cpp.o
[ 68%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_FreezeFrame.cpp.o
[ 70%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_ImageSequenceReference.cpp.o
[ 71%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Composable.cpp.o
[ 72%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Item.cpp.o
[ 74%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Composition.cpp.o
[ 75%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Gap.cpp.o
[ 76%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_UnknownSchema.cpp.o
[ 77%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Transition.cpp.o
[ 79%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Clip.cpp.o
[ 80%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Stack.cpp.o
[ 81%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Track.cpp.o
[ 83%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Timeline.cpp.o
[ 84%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Algorithms.cpp.o
[ 85%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Serialization.cpp.o
[ 87%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_Deserialization.cpp.o
[ 88%] Building CXX object src/main/cpp/CMakeFiles/jotio-1.0.0.dir/io_opentimeline_opentimelineio_OTIOTest.cpp.o
[ 89%] Linking CXX shared library ../../../lib/Release/Darwin/libjotio-1.0.0.dylib
[100%] Built target jotio-1.0.0

BUILD SUCCESSFUL in 41s
9 actionable tasks: 8 executed, 1 up-to-date
[eric@Slabby:~/Projects/otiojava/OpenTimelineIO/src/java-opentimelineio]$ git diff
diff --git a/src/java-opentimelineio/src/main/cpp/io_opentimeline_opentimelineio_Any.cpp b/src/java-opentimelineio/src/main/cpp/io_opentimeline_opentimelineio_Any.cpp
index 86f659a..0e529fd 100644
--- a/src/java-opentimelineio/src/main/cpp/io_opentimeline_opentimelineio_Any.cpp
+++ b/src/java-opentimelineio/src/main/cpp/io_opentimeline_opentimelineio_Any.cpp
@@ -41,7 +41,7 @@ Java_io_opentimeline_opentimelineio_Any_initializeInt(
  */
 JNIEXPORT void JNICALL Java_io_opentimeline_opentimelineio_Any_initializeLong
         (JNIEnv *env, jobject thisObj, jlong longParam) {
-    any anyValue = create_safely_typed_any(std::move(longParam));
+    any anyValue = create_safely_typed_any(std::move((int64_t)longParam));
     setHandle(env, thisObj, new any(anyValue));
 }

This should have run the tests as well, right?

@KarthikRIyer
Copy link
Contributor Author

@reinecke yes this should have run the tests as well. I'll make the change n push it.

@KarthikRIyer
Copy link
Contributor Author

KarthikRIyer commented Sep 4, 2020

This is w.r.t Windows.
Fixed some size_t to jsize warnings. There are still some pointer truncation warnings:

D:\OpenTimelineIO\src\java-opentimelineio\src\main\cpp\io_opentimeline_OTIONative.cpp(217,49): warning C4311: 'reinterpret_cast': pointer truncation from 'T *' to 'long' [D:\OpenTimelineIO\src\java-opentimelineio\build\natives\src\main\cpp\jotio-1.0.0.vcxproj]
          with
          [
              T=opentimelineio::v1_0::Track
          ]
D:\OpenTimelineIO\src\java-opentimelineio\src\main\cpp\io_opentimeline_OTIONative.cpp(217,49): warning C4302: 'reinterpret_cast': truncation from 'T *' to 'long' [D:\OpenTimelineIO\src\java-opentimelineio\build\natives\src\main\cpp\jotio-1.0.0.vcxproj]
          with
          [
              T=opentimelineio::v1_0::Track
          ]

long on 64-bit Unix/Linux is 64-bit, but on 64-bit Windows, it's 32-bit. So I need to cast to long long instead. But some of the tests are failing with this change. Will need some time to look into this.

@meshula
Copy link
Collaborator

meshula commented Sep 5, 2020

Hi Karthik, long and long long aren't guaranteed to be able to hold a pointer, hence the warning. uintptr_t is what you are looking for if you want an integer to hold a pointer, that will work on all platforms. If you want to be able to calculate offsets with pointers, use ptrdiff_t.

@KarthikRIyer
Copy link
Contributor Author

@meshula thanks for the suggestion. It worked! But I thought, why not directly cast to jlong when that's what we need to return. And that worked too. Now all warnings fixed on Windows.

@margant
Copy link

margant commented Sep 5, 2020 via email

@KarthikRIyer
Copy link
Contributor Author

@margant @meshula @reinecke do you think this is good to merge? This thread seems to have become very long. It's becoming a little difficult to find old conversations.

Also @meshula what do I need to do if we want to separate this into a different repo? It might be easier to update the bindings if we use the OTIO core as a submodule instead.

@meshula
Copy link
Collaborator

meshula commented Sep 6, 2020

OpenTimelineIO as a submodule mages sense, lets proceed in that direction!

@ssteinbach
Copy link
Collaborator

@margant @meshula @reinecke do you think this is good to merge? This thread seems to have become very long. It's becoming a little difficult to find old conversations.

Also @meshula what do I need to do if we want to separate this into a different repo? It might be easier to update the bindings if we use the OTIO core as a submodule instead.

I think there are two easy possibilities:

  1. You create an empty repo under your user name, and put this repo into that. People can file issues for notes on feedback.
  2. We make an empty repo under the "OpenTimelineIO" GitHub organization called OpenTimelineIO-JavaBindings (or whatever is a better name for this) and you open a pull request to that with your code.

Either way we can take it to the TSC to see what the community thinks of that approach.

Thoughts?

@KarthikRIyer
Copy link
Contributor Author

Is there an OTIO GitHub org or do we create the repo under the ASWF org?
I think putting it under OTIO org or ASWF would be better. It will be consistent with everything else when we split out other bindings or otioview into separate repos too.

@meshula
Copy link
Collaborator

meshula commented Sep 6, 2020

PixarAnimationStudios/OpentimelineIO-java would be my vote, because part of the GSOC delivery requirements be that the code reside in an organization's repo, rather than the contributor's.

In terms of splitting out the repo, for Imath, Owen @oxt3749 performed a magic trick whereby only Imath relevant commits landed in the new repo - thus preserving history and having it focussed only on Imath ~ perhaps he could tell us how he did it?

@KarthikRIyer
Copy link
Contributor Author

@meshula AFAIK GSoC doesn't require the code to reside in the org's repo. My last GSoC code resides under my username. But I still prefer your suggestion.

@ssteinbach
Copy link
Collaborator

@meshula AFAIK GSoC doesn't require the code to reside in the org's repo. My last GSoC code resides under my username. But I still prefer your suggestion.

I can walk @KarthikRIyer through the git steps to filter the history, I've done that before. Let me do a little research on Tuesday and I'll set up the pieces after this weekend.

@KarthikRIyer
Copy link
Contributor Author

KarthikRIyer commented Sep 6, 2020

@meshula @ssteinbach I used git cherry-pick to get the necessary commits. Here: https://github.com/KarthikRIyer/otio-java

Now I can change the directory structure and use OTIO as submodule.

@ssteinbach
Copy link
Collaborator

Perfect - go ahead with that. I need to poke legal/ASWF to figure out where the right spot to land this is and what boiler plate needs to go into the repo so that its set up correctly from ASWF's point of view. Thanks @KarthikRIyer!

@KarthikRIyer
Copy link
Contributor Author

Added a simple README. And GitHub Actions for ubuntu, windows and mac. https://github.com/KarthikRIyer/otio-java/actions/runs/242947255

@ssteinbach
Copy link
Collaborator

Ok here you go: https://github.com/OpenTimelineIO/OpenTimelineIO-Java-Bindings

Make sure you include a README.md and a .gitignore.

@KarthikRIyer
Copy link
Contributor Author

KarthikRIyer commented Sep 9, 2020

@ssteinbach do I need to change these : Copyright [yyyy] [name of copyright owner] in the LICENSE?

Should the java bindings also follow the same versioning as OTIO? So for the next release it should be 0.14.0?
We also need a bintray account.

@reinecke
Copy link
Collaborator

reinecke commented Sep 9, 2020

Someone double check me, but generally we use:Contributors to the OpenTimelineIO project for our copyrights.

@ssteinbach
Copy link
Collaborator

@KarthikRIyer Thanks again for all your hard work. For folks following along, the java bindings are now located at: https://github.com/OpenTimelineIO/OpenTimelineIO-Java-Bindings/

@ssteinbach ssteinbach closed this Jan 20, 2021
Google Summer of Code automation moved this from In Progress to Done Jan 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

9 participants