Add Appnotes describing external references and using OpenTimelineIO #104
Conversation
samdbmg
force-pushed
the
sammg-add-otio-appnote
branch
from
294480c to
dbd95bb
Compare
samdbmg
force-pushed
the
sammg-add-source-edit-adr
branch
from
cad2480 to
17f9746
Compare
samdbmg
force-pushed
the
sammg-add-otio-appnote
branch
from
dbd95bb to
46527b9
Compare
samdbmg
force-pushed
the
sammg-add-source-edit-adr
branch
2 times, most recently
from
d16817d to
d6a6691
Compare
Adds AppNote0014 describing external reference options for referring to TAMS content in other systems.
Adds an AppNote describing how OpenTimelineIO might be used with TAMS content.
samdbmg
force-pushed
the
sammg-add-otio-appnote
branch
from
46527b9 to
3e79b61
Compare
| @@ -0,0 +1,78 @@ | |||
| # 0014: Referencing TAMS content in other systemss | |||
There was a problem hiding this comment.
| # 0014: Referencing TAMS content in other systemss | |
| # 0014: Referencing TAMS content in other systems |
|
|
||
| This is intended to be a working document, and as new use cases are built out, new formats may be added. | ||
|
|
||
| ### URI References |
There was a problem hiding this comment.
I imagine an identifier not tied to a particular TAMS would be useful to have as well. I.e, should location and identity be separable? Maybe the identifier follows the same structure but doesn't have the location part and is a URN?
I think this question is probably covered by the String references section.
|
|
||
| #### Referring directly to a Source | ||
|
|
||
| When referring to an "asset" that contains, for example, video and audio (e.g. attaching a clip in a MAM to an underlying TAMS concept), the reference should point to the relevan t multi-essence Source. |
There was a problem hiding this comment.
| When referring to an "asset" that contains, for example, video and audio (e.g. attaching a clip in a MAM to an underlying TAMS concept), the reference should point to the relevan t multi-essence Source. | |
| When referring to an "asset" that contains, for example, video and audio (e.g. attaching a clip in a MAM to an underlying TAMS concept), the reference should point to the relevant multi-essence Source. |
| `` | ||
| ``` | ||
|
|
||
| ## JSON Object References |
There was a problem hiding this comment.
Ideally all our UUID strings would be represented as URNs, but maybe it's too late to change all of that and just use bare UUID strings. Related to that is that we've chosen to not include the type of thing been identified (Source or Flow for example).
I see this is covered by the Live Signal Domain section which advocates for alignment with NMOS.
| This format refers to a URL in a TAMS instance and points to a specific, concrete Flow. | ||
| It is possible a Clip could have more than one `ExternalReference` object (e.g. for each Flow), with the appropriate default selected: this allows, for example, online and proxy workflows to be presented in a UI. | ||
|
|
||
| Notice that the URL has a prefix `tamss://` (for "TAMS Secure" - `tams://` would also work for HTTP). |
There was a problem hiding this comment.
I wonder whether it is simpler to just have a tams:// pseudo-protocol. If secure/non-secure is an option then I don't see why this tams locator needs to decide either way - that's for the linker to decide when translating to the actual protocol.
Is it worth stating why you would use tams:// rather than https://, given that they look essentially the same?
Given my comments on 0014, one option would be to separate out the TAMS location (e.g. the base url). This might make it easier for linkers that want or need to use a different location to have the identity part separate from the (assumed / default) location. However, it's just a thought and I'm not advocating changing the design here.
| The TAMS identity model is deliberately aligned with that of [AMWA NMOS MS-04](https://specs.amwa.tv/ms-04/releases/v1.0.0/docs/2.1._Summary_and_Definitions.html), to facilitate alignment of fast-turnaround, live and file-based workflows. | ||
| It is expected that when content is ingested into TAMS in an NMOS environment, the Flow and Source IDs and internal timing of that content is preserved and can be considered as part of a unified control system. | ||
|
|
||
| When content is played out into a live signal environment, it is likely to be time-shifted to align with other content, which requires that a new Source and Flow ID be assigned (as described in the [MS-04 Playout Server example](https://specs.amwa.tv/ms-04/releases/v1.0.0/docs/3.2._Composite_Media_Operations.html#playout-server)). |
There was a problem hiding this comment.
This is a good use case for having the lightweight copy option.
|
|
||
|  | ||
|
|
||
| This makes the render process faster (references are a very "cheap" metadata operation), makes more efficient use of storage, and avoids an additional decode-encode cycle on some of the content. |
There was a problem hiding this comment.
(repeating discussions that have been had and the description further below)
and the reason for having those references in TAMS rather than keeping it in an external EDL is that it adds the bits that would otherwise to missing from the Flow that contains the new material segments - it becomes more a published artefact rather than an ephemeral work-in-progress artefact.. It can then be played back by processes that may not have the capabilities to render (parts of) the EDL. Although the other option is to pass a flattened EDL that contains the missing references to other Flows.
Details
Jira Issue (if relevant)
Jira URL: https://jira.dev.bbc.co.uk/browse/CLOUDFIT-3522
Related PRs
Builds on and implements parts of #90
Submitter PR Checks
(tick as appropriate)
Reviewer PR Checks
(tick as appropriate)
Info on PRs
The checks above are guidelines. They don't all have to be ticked, but they should all have been considered.