ISO IEC 23001-4:2011 pdf – Information technology一MPEG systems technologies – Part 4: Codec configuration representation
ISO IEC 23001-4:2011 pdf – Information technology一MPEG systems technologies – Part 4: Codec configuration representation.
• the (internal) state of the FU,
• the priority of that action (see below).
An FU may contain any number of actions. Its execution follows a simple cycle:
1) Determine, for each action, whether it is enabled, by testing all the conditions specified in that action.
2) If one or more actions are enabled, pick one of them to be tired next.
3) Execute that action. i.e. make the transition defined by it.
4) GotoStepi.
Steps I and 2 are called “action selection,” For many complex FUs, such as the parser of an MPEG-4 SP decoder, defining the logic of how an action Is chosen is the core of the implementation of the processing in FU form. RVC-CAL provides a number of language constructs for structuring the description of how actions are to be selected for bring. These include:
• action guards: conditions on the values of input tokens and/or the values of FU state variables that need to be true for an action to be enabled:
• finite state machine: the action selection process can be governed by a finite state machine, with the execution of an action causing a transition from one state to the next:
• action priorities: actions may be related to each other by a partial priority order, such that an action will only execute if no higher•prionty action can execute.
In this way, the process of action selection is specified in a declarative manner in each RVC FU. As a result, the FU specification becomes more compact and easier to understand.
Once selected, an action is executed. The code describing an action itself is for the most part orcnary imperative code, as can be found in languages such as Pascal, Ada, or C — there are loops, branches, assignments etc. Only the token input/output of an action is specified separately and in a declarative manner.
In other words, the RVC-CAL language provides naturally the appropriate constructs that have been identified by RVC requirement work as essential elements for building the MPEG RVC framework with the capacity of “encapsulating” coding tools functionahtles in a very natural manner without neeng any particular restriction or specific coding style on the usage of the language construct.
D.2 Introduction
This Annex describes RVC-CAL a profile of the CAL actor language to be used by the MPEG Reconfigurable Video Coding Framework.
Actors. The concept of actor as an entity that is composed with other actors to form a concurrent system has a rich and varied history — some important mIle-stones (6), (9], (3], [4). [5). A formal descrçtlon of the notion of actor underlying this specification can be found wi Dl, which is based on the work in [10] and (7). Intuitively. an actor is a description of a computation on sequences of tokens (atomic pisces of data) that produces other sequences of tokens as a result. It has input port(s) for receiving its input tokens. and it produces its output tokens on its output pof’t(s)1.
The computation performed by an actor proceeds as a sequence of atomic steps called rings, Each ring happens in some actor state, consumes a (possibly empty) prefix of each input token sequence, yields a new actor state. arid produces a finite token sequence on each Output port.
Several actors are usually composed into a network, a graph-like structure (often referred to as a model) in which output ports of actors are connected to input ports of the same or other actors, indicating that tokens produced at those output ports are to be sent to the corresponding input ports. Such actor networks are of course essential to the construction of complex systems, but we will not discuss this subject here, except for the following observations.