Explanation –Source
←Summary and Definitions · Index↑ · Explanation - Flow→
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 theseFlows. 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 eachFlowto aSourceSO THAT users are able to discover theFlows 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
Flowand a compressedFlow. - A video camera produces just an uncompressed
Flowwhich is then transcoded in a separate device to produce a compressedFlow.
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 aSourcemust “appear the same” when rendered / decoded (other than differences in quality / accuracy). This constraint means, for example, that theFlows in aSourcecan 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 theFlows belonging to aSourceintroduce 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 sameSource– this constraint would not be practical to enforce. However, clearly aSourceis most useful if all eligibleFlows are members (for example, it is generally better if oneSourceis used rather than two if this is permitted by the scenario and by the definition ofSource). - A
Sourceplaces no constraint on theTime Values used in aFlow. For example, there might beFlows associated with aSourcethat use different video sample rates. And note that for some audio codecs the “sample rate” is only decided upon decode anyway. - A
Sourcecan have zeroFlows. This could be practically useful because aSourcemight be created before its memberFlows; when thisSourceis initially created there could be a description of the nature of theFlows that it will contain. ASourcecan also have meaning / utility completely independently of itsFlowmembers. - All of the
Flows associated with aSourceuse the sameTime Context. This means that it makes sense to consider querying aSourcewith aTime Valueor range ofTime Values – this could be useful, for example, in designing an API that allows aSourceto be queried by time range without consideration of the video codecs of the associatedFlows.
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 aSource(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 aSource. ASourcebecomes less reliable as a contract for interoperability. - It would be possible to say that any
Flowcan be a member of aSourceas long as the manner in which its content differs is signalled in the technical metadata of theFlow. 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 aFlowand deciding whichSourceit should belong to it is probably unaware of the technical metadata that will be made available along with thatFlowlater on (for example, theFlowmight be available through a number of different APIs).