Networked Media Open Specifications

Explanation –Flow

←Explanation - Source · Index↑ · Explanation - Flow Representation→

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

Understanding the Flow Entity

The intention is that a Flow (identified by a Flow ID) provides a simple way to identify a particular expression of a Source. A Flow is a timed-data interface that might be implemented in different ways. These different implementations of a Flow are called Flow Representations.

In general, it is important not to think of a Flow as something that is stored in a file or carried in network packets – that is a Flow Representation and is just one practical realisation of the Flow. The Flow ID carried along with, or associated with, this Flow Representation is of importance here. It is this Flow ID that identifies the content and the interface (that is, as well as identifying the content it communicates what can be expected when handling the data). It helps to inform the user about how the data can be handled. For example:

In each scenario a decision needs to be made about the level at which to set the Flow. The most practical level is chosen: this is the lowest level that is considered interesting for the scenario. A Flow might be set at a low level in which case all associated Flow Representations will be very similar. Alternatively, a Flow can be set at a higher level in which case the associated Flow Representations can be much more varied in how they implement the Flow.

There is a need to work across a very wide range of different scenarios (involving both media and data; that is, all kinds of content Sources). Across these scenarios there are practical reasons for handling data at different levels. In some scenarios, the sequences of bytes used to represent the data are of interest and this is the level we principally want to work at. In other scenarios, these sequences of bytes are not of interest and we principally want to handle the data at a higher (more conceptual) level. So, the lowest level that is interesting is at a different position in each scenario (at least when the most common operations are considered).

The need to handle data at different levels is illustrated in these simple examples:

Further examples of the levels at which a Flow might be set are explained alongside Flow Representations.

Even if Flow is set (for a particular scenario) at a much higher “level” than the Flow Representations, this does not mean that all levels below Flow are unimportant. The levels below that defined by the Flow are not considered interesting when interfacing with the data but they do need to be taken care of somewhere in the wider system; that is, these lower levels are critical to a successful data transfer but are not of interest once that transfer has completed.

It is typically important for technical metadata to be provided about a Flow. This “Flow metadata” will apply to all Flow Representations associated with the Flow. Some Flow Representations might have extra Flow Representation-specific technical metadata associated with them. Additionally, it is important that the level of the Flow is clearly defined – this level might also need to be communicated (using additional metadata properties) between devices.

Guidance on how Flows 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 Flow

General Notes

A Flow can be regarded as a collection of Entrys. This collection of Entrys does not have any fixed / defined ordering, although the Entrys can of course be ordered by Time Value if required. However, in some real scenarios there could be Time Value-based restrictions on the order in which Entrys can be added to an existing Flow (for example, for a live media Flow). Note: This relates to mutability of the model entities which is commented on in 4.0. Appendix - Commentary. Also refer to notes on the relationship between Grains and Entrys.

There is no constraint that requires the technical properties of a Flow to be static. For example, the dimensions of a video or its framerate could change over time – but these properties would change in the same way across all Flow Representations associated with the Flow.

There is also no constraint that all Flow Representations which match the technical properties of a particular Flow must be part of that Flow – this constraint would not be practical to enforce. However, clearly a Flow is most useful if all eligible Flow Representations are members (for example, it is generally better if one Flow is used rather than two if this is permitted by the scenario and by the definition of Flow).

Interpretation of a Flow (for example, “rendering” of the Flow) will depend on the exact data types etc used. For example:

Notes on Data Objects

←Explanation - Source · Index↑ · Explanation - Flow Representation→

Documentation built at 04:51:55 CDT on 2024-08-29.
(c) AMWA 2024. RAML/JSON licensed under Apache 2.0. Documentation licensed under CC BY-ND 4.0.