Skip to content

Long term architecture

curiousercreative edited this page Apr 28, 2014 · 5 revisions

Long term, we have the following major types of objects:

  1. Media
  2. Stories

Each of these will have the following fields in common (see HitRecord for example of similar fields):

  • Derivative works - A list of stories that include this object or includes an object including this one all the way up the chain.
  • Cited works - A list of objects or external resources that are included in this object or in an included object all the way down the chain.
  • Contributors - A list of contributors + credit for this object or a cited work all the way down the chain.
  • Activity log - A log of events for this object and it's ancestor object (finished cut should include the activity of all previous stories and media similar to a git commit log. Imagine the finished film's log!)
  • Download - Each object can be downloaded, simple for media which is a single A/V file, but for stories is the package with instructions for getting it into your video editor along with all the referenced media.

Media (AKA clips)

External media that shouldn't ever be changing. It gets added to the repo, linked externally and isn't tracked. These media will be edited together into stories. We have previously created, or gathered this media for import into LogC and once imported, LogC won't be modifying these.

Media Type

Each media bit is one of the following types:

  • video - Video is our primary medium for LogC.
  • audio - audio will primarily be music but in some cases may contain the narrative
  • still image - typically a still photo or graphic (we shouldn't care much for these)

Media state

Each piece of media fits into one of the following states:

  • source clip - This media was recorded in the field and hasn't been edited. If this clip is video, it's a low-resolution "offline" clip that is named the same as a much larger full-resolution "online" clip that will later be used. Source clip objects are aware of all story objects that include them. Source clips have public interfaces where media notes can be entered.
  • story rendering - This media contains source clips edited together into a story. Story renderings appear in a different interface from source clips and only exist as a visualization of the story.

Media Roles

Each piece of media should fit into one of these roles:

  • Interview (aka talking head)
  • B-roll
  • Music

Media Tags (Story)

Tags for indicating which story topics this media relates to.

Media Tags (Misc)

Tags to describe the framing, angle, camera movement, day or night, interior or exterior, etc, etc

Media Notes

Each video or audio should have timecode specific notes about what is going. This makes it easier for us to find what we're looking for later on. There are two types of media notes:

  1. Transcription - A text translation of what is being said in the video
  2. Log note - A text description of what is happening in a shot

Story (AKA sequences)

Stories are what we are creating and using LogC to aid with. Where our media objects aren't tracked and versioned, simply imported once, our stories are ever evolving and require version tracking. We want to see every saved version of a story. We also want to see what the story is constituted of, what other stories does it include and what media is included. We also want to see an activity log with events such as story created,

On the technical end of things, each story has two components:

  1. Plain-text XML file with instructions for assembling the story from the necessary media.
  2. A rendered binary video of the story according to the instructions. Stories are comprised of media and other stories.

Story States

There are several states of stories, each of them a progression of a previous:

  • Selects or string-out - After an interview or event has been logged, a very crude string-out of the interview sound bites or event highlights will be put together. This is created for others to quickly see/hear the highlights without watching the entirety of the source media. We shouldn't plan to have more than one version of a string-out.
  • Assembly - An assembly is similar in crudeness to the string-out except it's telling a story now and is typically made from relevant bits of multiple string-outs. This assembly is a rough outline of the story and there may be multiple versions.
  • Rough cut - The alpha release of the story. The rough cut starts where an assembly left off exactly and turns the outline into a story. Pacing, graphics, b-roll and music are all being orchestrated, but still up in the air. There will be multiple versions of a rough cut.
  • Fine cut - The beta release of the story. The fine cut picks up where the rough cut left off exactly and finalizes the pacing and placement of all graphics, b-roll and music. This final cut will be taken online and finished by a single editor.
  • Finished cut - The release candidate of the story. The finished cut is the final cut with color corrections applied and any scoring, sound design and mixing.