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

[DRAFT] Project schema proposal #683

Conversation

apetrynet
Copy link
Contributor

Hi!
As touched upon briefly in the last couple of TSC meetings, here is an initial proposal for a Project schema definition.
It's written i python at the moment so this PR is mostly for discussion and to get the ball rolling on a full fledged Project schema.

Some motivation for a Project schema:

  • Have a single entry point for collecting several timelines (sequences, episodes, etc.), collection of clips, media references and so on.
  • Some metadata is more natural to store under a project umbrella than a timeline like: OCIO config path, media search paths, etc.
  • Adding a Project schema will allow users to exchange not only individual timelines, but complete project structures across applications.
  • In combination with something like the proposed file bundle Add filebundle (otioz and otiod) adapters #561 adapter one could archive/consolidate a complete project including clips/media references outside of a timeline.

I did a quick "survey" of the project settings of Premiere, Final Cut, Hiero and Davinci and naturally they all have some variations, but all of them share the concept of "bins" and have a notion of these settings:

  • frame rate (default frame rate for new timelines)
  • resolution (viewer/render resolution)
  • colorspace (viewer lut or colorspace of media)

In my proposal I chose to name our "bins" holder; collections to refer to the SerializableCollection objects that it could store, and a separate timelines attribute which should hold Timeline objects (duh..)
I also chose to call the rate, resolution and colorspace:

  • viewer_rate
  • viewer_resolution
  • viewer_lut

as these settings usually only apply to the viewer of an applications project file.

Example in python:

import opentimelineio as otio

p = otio.schema.Project('myProject')
bin = otio.schema.SerializableCollection('myclips')
t = otio.schema.Timeline('myTimeline')
p.collections.append(bin)
p.timelines.append(t)

otio.adapters.write_to_file(p, 'project_test.otio')

Results:

otiocat project_test.otio 
{
    "OTIO_SCHEMA": "Project.1",
    "collections": [
        {
            "OTIO_SCHEMA": "SerializableCollection.1",
            "metadata": {},
            "name": "myclips",
            "children": []
        }
    ],
    "timelines": [
        {
            "OTIO_SCHEMA": "Timeline.1",
            "metadata": {},
            "name": "myTimeline",
            "global_start_time": null,
            "tracks": {
                "OTIO_SCHEMA": "Stack.1",
                "metadata": {},
                "name": "tracks",
                "source_range": null,
                "effects": [],
                "markers": [],
                "children": []
            }
        }
    ],
    "viewer_lut": null,
    "viewer_rate": null,
    "viewer_resolution": [
        null,
        null
    ],
    "metadata": {
        "OCIO_PATH": null
    },
    "name": "myProject"
}

Again, this is an initial proposal to get the ball rolling. All comments, ideas and views are welcome :)
Thanks!

@apetrynet
Copy link
Contributor Author

apetrynet commented Jul 14, 2020

I'm closing this pull request as I now realize it might not be the best way to go. The idea of a root bin seems like a better approach. We'll still have a place to store several timelines and clips etc. without having to adapt to every application out there with regards to project settings and so on.

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