Appendix - Commentary
←Media Production Chains · Index↑
Background to this Specification
A large quantity of draft documentation was generated in generating MS-04. This additional documentation records the analysis which was carried out and the decisions made in order to reach the conclusions made in this specification.
The detail contained within this additional documentation will not be of relevance to most readers of this specification. However, the authors felt it important for this be retained. These documents are included in an archive directory so that any future queries raised against this specification can be considered using the same framework and analysis originally used to develop the specification.
Use of the Terms Source and Flow
Existing & Casual Usage
As with many concepts, the terms Source and Flow have been overloaded in their usage over time. This model makes use of these terms in order to remain consistent with the JT-NM Reference Architecture which it is based upon, however the reader should be aware that usage in this model should not be confused with the following cases:
- The term “source” can sometimes be used to refer to a group of signals which both originate from and terminate at a particular location. One common example of this is in the concept of an “outside source”. A
SourceID in this model only ever refers to the grouping of a set ofFlows which express the same content. - The term “flow” can sometimes be used to refer to a stream of packets which are carried over an IP network. Use of the term
Flowwithin this model is not limited to characterising content as it transits a network, and a “network flow” has stronger parallels with one of potentially severalFlow Representations.
JT-NM & NMOS Definitions
The JT-NM Reference Architecture contains the following definitions, with similar definitions repeated in the AMWA IS-04 specification:
“Source”: an abstract concept that represents the primary origin of a “flow” or set of “flows”
“Flow”: a sequence of Grains from a source; a concrete representation of content emanating from the Source
This specification extends these definitions whilst attempting to remain compatible with them in order to clarify their intended usage within NMOS specifications. Justification for these extensions and clarifications is contained within the Explanation - Source and Explanation - Flow documents.
In the JT-NM Reference Architecture, Grains are used as a way to attach pieces of timing information to pieces of data. Further work is needed to provide guidance on how Grains are handled using this model – see below.
Possible Extensions
Opportunites for extending and further documenting the model are described below:
Further Develop Ancestry and Grouping Modelling
Some foundations on ancestry and grouping are presented in this specification. Develop these areas into usable additions to the identity and timing model.
Address Mapping of the Identity and Timing Model to Grains
Provide guidance on how the existing NMOS concept of Grains should be handled using the identity and timing model presented in this specification. In practical applications Grains are used as a container for communicating Flows. Each Grain can be used to contain multiple pieces of data and sometimes multiple
pieces of timing information for each piece of data. As such, there is a relationship between Grains and Flow Representations – this would need to be modelled. Note that a Grain behaves differently to an Entry. For example, an audio Flow could have Entrys corresponding to audio samples; potentially this could be communicated using Grains that each contain numerous audio samples.
Explain How the Model is Used with Practical Clocks
Provide guidance on how practical clocks should be handled using the identity and timing model. This includes addressing how Time Contexts should be used when a number of imperfect/inaccurate clocks are in use within a system.
Address Time Value Uniqueness in Flows
The model currently does not mandate that Time Values are unique within a Flow although this will be the case in many practical media scenarios. There are both advantages and disadvantages (particularly in relation to “events”) to introducing such a constraint either in the model or in accompanying application-specific guidance.
Provide Guidance on Mutability of Entities as Used in Real Scenarios
The extent to which real instances of the model entities (such as Flows) should be mutable will likely depend on the application scenario. Different kinds of content might have different characteristics (such as the addition of Data Objects being expected anywhere within stored media Flows but live media flows being “append only”).
Further Develop Explanation on Time Value Representations
Some consideration is given to representations of Time Values in this specification. Further develop this work to include additional real-world considerations such as phase offsets from timing based on a media rate.