Skip to content

Explanation –Source

Please ensure you have read the Summary and Definitions before considering the further detail covered by this page.

Understanding the Source Entity

The intention is that a Source (identified by a Source ID) provides an easy and convenient way to refer to a time-based signal or content in a manner that is agnostic to the means used to express it and the exact quality / accuracy of the expression. This use of the term Source should not be confused with the casual use of the word source to refer to multiple media signals relevant to an 'outside source' or similar (see the Appendix).

It is useful to appreciate that a Source represents what its member Flows have in common – that is, the time-based data that they all represent. The Source entity allows the content to be referred to without needing to refer to a specific Flow. In some scenarios it might be helpful to think of the Source as identifying the result of running a particular query on the ancestry relationships associated with a collection of Flows.

The Source entity has been defined so that a Source is practically useful and aids in interoperability. As a result, a Source ID can be:

  • used in establishing a clear "contract" between devices, users, etc. Example use case:

AS A user of a music API I NEED TO discover the different representations of a recording available SO THAT I can choose the most practical representation for the device I am using at the time.

  • used as a means to identify a number of Flows that are considered to be equivalent in terms of the time-based content they are conveying. This allows common creative / content-level processing actions to be defined and then applied across all of these Flows. Example use case:

AS A person editing a video programme I NEED TO express my edit decisions SO THAT whichever representations of the programme are generated it will appear as I intended (I accept that these representations might be of different qualities for practical reasons).

  • assigned / managed automatically in many common scenarios. Example use case:

AS A device that creates Flows I NEED TO know how to assign each Flow to a Source SO THAT users are able to discover the Flows that they require.

A Source will sometimes be associated with a particular physical device but this is not necessarily the case. Consider the following two scenarios:

  • A video camera produces both an uncompressed Flow and a compressed Flow.
  • A video camera produces just an uncompressed Flow which is then transcoded in a separate device to produce a compressed Flow.

In each scenario the two Flows are expressions of a single Source – the physical device that produced each Flow is not relevant from a content processing perspective. It is already possible to identify the device that created a Flow using that device's own identity (see AMWA IS-04).

It is important to understand that a Source cannot be used to describe arbitrary similarities between Flows: all Flows that are expressions of a Source must "appear the same" when rendered / decoded (other than differences in quality / accuracy). Additional Flows that are similar but do not meet this constraint will need to be associated with a different Source; other mechanisms will then be needed to describe the similarity between these Sources.

Guidance on how Sources can be applied to the handling of video and audio can be found in 3.0. Practical Guidance for Media

Notes on the Formal Definition of Source

  • All Flows that are expressions of a Source must "appear the same" when rendered / decoded (other than differences in quality / accuracy). This constraint means, for example, that the Flows in a Source can use different video codecs. However, differences that result in a variation in the time-based data are not permitted unless these are only differences in "quality" (for example, due to lossy compression). Relating it back to the "person editing a video programme" use case listed above: none of the Flows belonging to a Source introduce changes that a user of a video editing tool would find surprising; none of the changes relate to properties or operations that the user would change for creative reasons.
  • There is no constraint that all Flows satisfying these conditions must be part of the same Source – this constraint would not be practical to enforce. However, clearly a Source is most useful if all eligible Flows are members (for example, it is generally better if one Source is used rather than two if this is permitted by the scenario and by the definition of Source).
  • A Source places no constraint on the Time Values used in a Flow. For example, there might be Flows associated with a Source that use different video sample rates. And note that for some audio codecs the "sample rate" is only decided upon decode anyway.
  • A Source can have zero Flows. This could be practically useful because a Source might be created before its member Flows; when this Source is initially created there could be a description of the nature of the Flows that it will contain. A Source can also have meaning / utility completely independently of its Flow members.
  • All of the Flows associated with a Source use the same Time Context. This means that it makes sense to consider querying a Source with a Time Value or range of Time Values – this could be useful, for example, in designing an API that allows a Source to be queried by time range without consideration of the video codecs of the associated Flows.

Commentary on How Source is Defined

Broader definitions of Source were considered (that is, definitions that would permit more Flows to be members) but these were found to be problematic when analysing against the intended purpose of a Source.

For example:

  • If greater changes are permitted to the content represented by Flows within a Source (such as converting a colour image to monochrome or allowing a crop of a video) then it becomes more difficult to define the boundary of a Source. A Source becomes less reliable as a contract for interoperability.
  • It would be possible to say that any Flow can be a member of a Source as long as the manner in which its content differs is signalled in the technical metadata of the Flow. However, this technical metadata could potentially be very complex (to support the description of very complex content alterations) and not supported by all devices. Also, when a device is creating a Flow and deciding which Source it should belong to it is probably unaware of the technical metadata that will be made available along with that Flow later on (for example, the Flow might be available through a number of different APIs).