|
|
## The Frame Class
|
|
|
# The Frame Class
|
|
|
Data is synchronised and organised into discrete frames that are represented by a `Frame` class. This page outlines the requirements and chosen design for this class since it is central to the entire system
|
|
|
|
|
|
### Requirements
|
|
|
## Requirements
|
|
|
### Terms
|
|
|
* **Frame** represents the state of some source entity at a discrete time point.
|
|
|
* **Flushing** is the saving of and transmission of the frame, completing the state transaction at that discrete time point.
|
|
|
|
|
|
### 1. Contents of a Frame
|
|
|
**1.1** Contains up to an unsigned 32bit number of data channels.
|
|
|
**1.2** Channels bellow 32 are fixed to `VideoFrame` type.
|
|
|
**1.2.1** `VideoFrame` channels have a non-persistent storage status.
|
|
|
**1.3** Channels between 32 and 64 are fixed to `AudioFrame` type.
|
|
|
**1.3.1** `AudioFrame` channels have an accumulate recent changes storage status.
|
|
|
|
|
|
### 2. Creating and Modifying
|
|
|
**2.1** A `Feed` class must manage the creation of frames.
|
|
|
**2.2** A `Frame` can be modified only prior to flushing (aka. transmission).
|
|
|
**2.3** Modifications after flushing are discarded.
|
|
|
**2.4** A `Frame` can only be flushed once.
|
|
|
**2.5** Modifications prior to flushing are local to the frame only.
|
|
|
**2.6** Frames are given a unique source identifier by `Feed`.
|
|
|
**2.7** `Frame` id and timestamp together are unique within the feed.
|
|
|
**2.8** Local modifications override any other change status for a channel.
|
|
|
|
|
|
### 3. Receiving Frames
|
|
|
|
|
|
### 4. Transmitting Frames
|
|
|
|
|
|
## Discussion
|
|
|
Each frame is involved in a number of stages within the system, these are:
|
|
|
1. Formation
|
|
|
2. Transmitting
|
... | ... | |