5 Media-type definition

26.1423GPPDynamic and Interactive Multimedia Scenes (DIMS)Release 17TS

5.1 Introduction

The DIMS media type allows spatial and temporal layout of the multimedia scene. This scene can consist of any combination of still pictures, video, audio, and animated graphics. It includes an update mechanism that allows for partial updates of the existing scene, as well as updating the presentation with a completely new scene and streaming tune-in functionality.

5.2 Media type components

The DIMS media type consists of:

– Base scene description, which is SVG Tiny 1.2 [1].

– Scene description extensions.

– Scene commands.

– Event generation and processing.

5.3 Namespace

The namespace called DIMS here is associated with the URN "http://www.3gpp.org/richmedia/".

5.4 Scene description

5.4.1 Base Scene Description

SVG Tiny 1.2 provides the basic DIMS Scene functionality; layout, inclusion and referencing of objects, synchronization of object timelines and a rendering model.

The full syntax and semantics of SVG Tiny 1.2 shall be supported for DIMS Scene functionality. The version and baseProfile attributes of the SVG element document the version and profile of SVG on which this scene is based.

5.4.2 Scene Description Extensions

5.4.2.1 Introduction

Extensions defined here are designed so that:

a) when the same functionality is present in profiles of SVG other than SVG Tiny 1.2, then the extension is compatible with that or a restricted version of that.

b) A terminal implementing both the present document and SVG (any version) can use a common implementation of the DOM tree, scene graph, rendering model etc. without having variant handling that depends on whether the scene was built using DIMS or SVG.

c) No extensions are required to be present in all documents; content authored to the SVG Tiny 1.2 specification may be used as the initial scene of a stream designed to the present document.

The following extensions are defined here.

5.4.2.2 Rectangular clipping of a graphical object

The lsr:rectClip mechanism provides pixel aligned clipping defined as a transformable rectangle.

The lsr:rectClip element shall be supported. The definition of lsr:rectClip is defined in subclause 6.8.28 of [3].

5.4.2.3 Full-screen video

The full-screen video feature consists of the attribute lsr:fullscreen on the SVG video element.

The lsr:fullscreen attribute shall be supported. The lsr:fullscreen attribute is defined in subclause 6.8.40.2 of [3].

See clause 10 for security considerations of fullscreen.

5.4.2.4 Full-screen SVG

The fullscreen SVG feature in the DIMS namespace consists of an attribute ‘fullscreen’ on the <svg> element to hint that the scene should be rendered on the full screen. The possible values are "true" and "false" (default). With the attribute set to true the DIMS UE should negotiate the rendering area with its parent UE and get as large part of the screen as possible for the DIMS canvas.

The dims:fullscreen attribute shall be supported on the svg element.

See clause 10 for security considerations of fullscreen.

5.4.2.5 Attributes clipBegin and clipEnd

Attributes clipBegin and clipEnd defined in subclause 7.6.1 of [5] shall be supported on the following elements: video, audio, animation, and the "updates" element as described in subclause 5.4.2.6.

5.4.2.6 Update Streams

The present document defines a new element ‘updates’ in the DIMS namespace to link secondary streams of updates to a scene. This element has an implicit "simple duration" of ‘indefinite’. The synchronization attributes defined in [1] subclause 12.6 can be used with this element.

The dims:updates element shall be supported.

NOTE: lsr:updates defined in subclause 6.8.53 of [3] is a superset of this element.

Attribute definitions:

All timing attributes defined in [1] subclause 16.2.7 are defined for this element, except the "fill" attribute.

The attributes clipBegin and clipEnd defined in subclause5.4.2.5, and syncReference defined in subclause 5.4.2.7, are defined for this element.

xlink:href = "<iri>"

An IRI reference to a source of updates, such as a DIMS stream/file. This attribute specifies the location of the stream of updates. In the absence of this attribute, this element does not have any effect. This attribute is not animatable and not inheritable. In DIMS, support is required only for DIMS streams or files.

5.4.2.7 Synchronization of Media Streams

lsr:syncReference = "<iri>"

The attribute lsr:syncReference from subclause 6.8.8.2 of [3] shall be supported on the elements video, audio, and animation from SVG, and ‘updates’ from the present document, with the associated synchronization behaviour. This attribute holds a reference to the stream or media element whose clock acts as a clock reference for the stream referred to by this element. This attribute is not animatable and not inheritable.

5.4.2.8 Screen orientation

Two events and two extension strings are defined that make it possible for scenes to adapt to the screen layout. The events are defined in subclause 6.1.3.

Whenever the terminal detects a change of orientation, angle, or screen size, one of these two events is dispatched. A portrait event is dispatched if the screen is taller than it is wide, and a landscape event is dispatched if the screen is wider than it is tall. It is the responsibility of the system below the scene to orient the screen buffer to user; the DIMS Scene author does not do this.

In addition, the orientation is reported in degrees in screenAngle, to the best of the terminal’s capability. This is measured as the angle between the positive X-axis of an un-rotated frame of reference, and the orientation of the longer of the positive X or Y axis of the screen, as rotated, as shown in Figure 5-1. Note that the SVG Y axis is downward.

Specifically, for a screen that is normally portrait and in its normal position, the screenAngle is 90 degrees, since the longest axis is vertical, and the Y-axis is downward in SVG. Similarly, for a terminal that is normally landscape and in its normal position, the screenAngle is 0 degrees, since the longest axis is horizontal, and is the X-axis. This angle therefore would normally be close to 90 or 270 in portrait events, and close to 0 or 180 in landscape events, and 0 or 90 in terminals that are in their normal orientation, and 180 or 270 in terminals that are inverted.

Figure 5-1: Screen Orientation

These events shall map to the ScreenOrientationEvent interface as defined in subclause 6.1.3.

The screen orientation events shall be supported in DIMS. If the terminal has an orientation sensor, or other physical adaptation that causes the available screen drawing area to change (e.g. a partial cover), events shall be generated whenever the terminal detects a change in any of the parameters to these events.

The following extension strings shall also be supported, in order to allow the use of the switch element:

– orientLandscape for typical ‘landscape’ orientation;

– orientPortrait for typical ‘portrait’ orientation.

The namespace of these feature strings is DIMS.

If the most recent event generated was a portrait event, then requiredExtensions="orientPortrait" tests as true; if the most recent event was a landscape event, requiredExtensions="orientLandscape" tests as true. At any time, exactly one of these requiredExtensions expressions shall test as true. If no event has been generated, the appropriate requiredExtensions expression tests as true.

Information on softkey location and key mapping may be found in section 9 of [26].

5.4.2.9 Current-Time Indication

In a Primary Stream, Redundant Random-Access Point there is a need to establish the current SceneTime of the scene, so that terminals tuning-in, performing random-access, or recovering from a lost high-priority DIMS Unit achieve the same SceneTime as terminals which had processed the entire stream from the most recent non-redundant Random Access Point. This media-time (scene time) is indicated by the currentSceneTime attribute on the SVG element, and takes a valid clock value in the document timeline, from the SVG specification [1].

The scene state is set exactly as if the SVG document had been loaded and displayed at the non-zero time T in the current-time indicator.

EXAMPLE: This is the same as if this SVG scene had been used in a SMIL document as the target of an "animation" element with clipBegin of T, or if conceptually all absolute times S in the document were replaced with S-T and the document instantiated at time 0.

Attribute definition:

currentSceneTime = "<clock-value>"

Specifies the current scene time (a valid clock value) in the document timeline, at which the scene is displayed. The scene state is set exactly as if the SVG document had been loaded and displayed at the non-zero time T in the current-time indicator. This attribute is defined in DIMS namespace, and may be present on the root SVG element in redundant random access points. The default value is zero.

5.4.2.10 Active attribute

On all elements, the following attribute is defined in the DIMS namespace:

active: this attribute defines whether the element is active. The possible values are "true" (default) and "false".

Setting the value of this attribute to true or false is equivalent to executing the commands activate and deactivate. See subclause 5.5.3 for the behaviour of deactivated elements. This attribute is not animatable and not inheritable.

The dims:active attribute shall be supported.

5.5 Scene Commands

5.5.1 Scene Updates

The scene update mechanism allows reception of updates that change parts of the current scene, without having to replace the entire scene.

To account for the different update scenarios two update mechanisms are defined:

– Primary-stream updates: Updates are delivered to the client in the same stream as the original scene.

– Secondary-stream updates: Updates are delivered to the client in separate streams from the original scene, e.g. in an interactive scenario or initiated from the scene mark-up.

In a primary-stream case, the updates and/or scene replacements are sent in the same stream as the initial scene. The temporal management of samples in a primary stream is based upon transport level timestamps. A secondary stream is a stream that does not contain the initial scene. A secondary stream is initiated directly from the DIMS mark-up using the ‘updates’ element.

The following LASeR commands from subclause 6.7 of [3] in LASeR ML format shall be supported.

– The LASeR Insert command from subclause 6.7.5 of [3] shall be supported on elements, attributes and values in list attributes with the following relaxed constraints: values may be inserted on attributes x and y of the text element.

– The LASeR Delete command from subclause 6.7.4 of [3] shall be supported on elements, attributes and values in list attributes.

– The LASeR Replace command from subclause 6.7.8 of [3] shall be supported on elements, attributes and values in list attributes with the following relaxed constraints: attributes attributeName, id, type, xml:space, preserveAspectRatio and the x and y attributes of the text element can be replaced. There are no restrictions on the value of attributeName. The text regarding executionTime does not apply.

– The LASeR Add command from subclause 6.7.2 of [3] shall be supported.

5.5.2 State management commands

The following state management commands shall be supported:

– The LASeR Save command from subclause 6.7.10 of [3] shall be supported.

– The LASeR Restore command from subclause 6.7.9 of [3] shall be supported.

– The LASeR Clean command from subclause 6.7.3 of [3] shall be supported.

These LASeR commands are defined as an interface to persistent storage. Selected scene information is cached on a best effort basis. The security principles behind this caching are those of the state caching mechanism in HTTP, commonly called cookies [23].

The saved data is defined by a groupID (known as "name" in [23]) and scoped by the "service" defined by a domain-name and path; for a command to operate on the data, all must match.

The LASeR command "save" saves the values of a set of attributes, each identified by element ID and attribute name. Each save operation uses a groupID. Any other saved state with the same domain-name, path, and groupID is replaced.

The LASeR command "restore" restores the attributes (if any) previously saved and scoped by the domain-name and path. The set of data restored is defined below.

The LASeR command "clean" erases the attributes (if any) previously saved and scoped by the domain-name and path. The set of data erased is defined below.

The following two attributes are defined in the stream signalling, and define the security restrictions for the above commands:

– useFullRequestHost: this Boolean attribute indicates whether the full domain-name of the request-host is used (true, 1) or the first component of the domain-name is elided (false, 0). For example, if the source material came from "www.example.org", then this differentiates between associating the "service" with "www.example.org" and ".example.org". (Note the definition of local names in [23], and the possibility to associate the "service" with locally loaded files, and that the domain-name may be either "<hostname>.local" or ".local" in that case.)

– pathComponents: this 4-bit unsigned integer attribute indicates how much of the source path is used. If this takes the value 0, then the "service" is not associated with a path, and if it takes the special value 15 (or any value equal to or greater than the number of components in the path) then the entire path is used up to but excluding the final file-name. For example, if the source was "/user/laser-expert/demo/art.mp4" then a value of 3 or greater selects "/user/laser-expert/demo" as the path, the value 2 selects "/user/laser-expert" and the value zero sets no path.

Data is saved as a set of four values, using the URI, pathComponents and useFullRequestHost from the stream containing the save command:

– the domain-name formed from the URI and useFullRequestHost;

– the path formed from the URI and pathComponents;

– the groupID;

– the set of {element-ID, attribute-name, value} triplets.

When a restore command is executed all saved sets with the same (equal) groupID, and also where the URI of the stream containing the restore command matches the saved domain-name and path, are restored. This matching is defined in section 3.3.4 of [23].

A clean command behaves exactly the same as a save command that saves no state; as is normal for the save command, any other saved state with the same domain-name, path, and groupID is replaced, in this case, with an empty set of saved data. This is functionally equivalent to deleting that saved state, as nothing would be restored.

NOTE: Be aware that though the data saved and restored is scoped by stream, once it is restored into the tree it is globally visible.

5.5.3 Activate and Deactivate

The commands activate and deactivate as defined in subclauses 6.7.12 and 6.7.13 of [3] shall be supported, in a manner that is functionally equivalent to that specification. These commands have one attribute:

– ref: the id of the element which is to be activated or de-activated.

When an element is deactivated, the system then treats the DOM tree as if that element and its descendents were not present in the DOM tree, and invisible to everything except commands and scripts. Commands and scripts can reference it as if it were still in the DOM tree. When activated, the element is then restored to visibility, in the same location in the tree as if it had not been previously deactivated.

The active attribute is not inherited. However, activated and de-activated events are generated if the effective active state of an element changes as a result of a change to the active state of a parent. This means that a deactivated event may occur for an element, as a result of deactivating a parent, when a test of its dims:active attribute value returns true.

5.5.4 Distributed Random Access Points

5.5.4.1 Introduction

A Distributed Random Access Point (DRAP) is a redundant DIMS tune-in point (either primary or secondary) that can, instead of explicitly defining all elements itself, reference elements in coming DIMS units. The commands in these following DIMS units are not executed, elements are simply copied according to references in the DRAP. These references can be used to reduce redundancy (i.e. not defining an element both in a RAP and an update) or to simply spread the size of the RAP over a period of time.

After this copying operation, the pending action(s) in the DRAP are complete, and are then executed, and normal processing resumes.

Figure 5-2: Illustration of the DRAP Concept

5.5.4.2 DRAP syntax and semantics

The rootmost element in a DRAP document shall be a <drap> element in the DIMS namespace. A DIMS Unit containing a DRAP shall contain only the DRAP.

Attribute definitions:

unitsrequired="units-required"

Indicates the number of coming DIMS units required.

NOTE 1: These DIMS units are not executed in the normal way when tuning in using DRAP; instead, they are used as needed as a source of material for the DRAP.

The DRAP element contains one or more getfromupdate elements, which form the processing instructions, and one or more other elements that form the pending action(s). The processing instructions are applied to the pending action. The indicated number of DIMS units are processed for the DRAP, and the pending action(s) are performed at the time of the DIMS unit at the indicated distance, and normal DIMS unit processing resumes.

NOTE 2: All the getfromupdates should have been resolved by the indicated distance.

The getfromupdate element shall reference an element in another DIMS unit and an element in the pending actions. The element referred to in the other DIMS unit shall replace the element in the DRAP pending actions.

Attribute definitions:

source="elementid"

Specifies an xml id appearing in an upcoming DIMS unit. If the same xml id appears in different DIMS units, it shall not make a difference which one the client chooses.

target="elementid"

Specifies an xml id appearing in the DRAP pending action(s).

5.5.5 Immediate Script Execution

The doScript command in the DIMS namespace shall be supported. This command supplies a script for immediate execution, including the ability to update the DOM. It has a single attribute, the type of the script. The script is in the body of the element. Processing this command involves executing the script in the context of the DIMS stream in which it occurs.

Attributes:

type – is a string that identifies the scripting language used. It takes a suitable MIME type [18] from the IANA registry, such as "application/ecmascript" (see [13]).

An example is:

<doScript type="application/ecmascript">
var root = document.documentElement;
var myGroup = document.createElementNS(
"http://www.w3.org/2000/svg", "g");
myGroup.id = "myGroup";
root.appendChild(myGroup);
var myRect = document.createElementNS(
"http://www.w3.org/2000/svg", "rect");
myRect.id = "myRect";
var color = root.createRGBColor( 255, 0, 0);
myRect.setRGBColorTrait("fill", color);
myRect.setFloatTrait("x", 10);
myGroup.appendChild(myRect);
</doScript>

5.5.6 Seeking in the DIMS Stream

<seek seekOffset="seekOffset" />

Attributes:

seekOffset: A clock value from subclause 16.2.7 of [1].

The command seek in the DIMS namespace results in a seek, by the amount seekOffset, in the DIMS stream timeline. The target stream time is obtained by adding seekOffset to the current stream time. As a DIMS stream may contain multiple scenes, this seeking can result in a change of scene. A seek to the local time corresponding to the seekOffset shall be applied to the (possibly new) scene. The seek command shall be supported.

NOTE: Seeking can be conceptually seen as a function where the global timeline and document timelines are moving forward in a synchronized manner, just as in normal playback, but more quickly and without rendering. A seek backwards in time (negative seekOffset) could be done in a similar way, but by starting again from zero and moving forward.

5.6 DIMS Unit Definition

5.6.1 Definition

A DIMS Unit is built from a header and a body. The DIMS Unit Body is either:

a) a complete SVG document as specified in subclause 5.4, possibly using extensions; or

b) a textually concatenated sequence of scene commands as specified in subclause 5.5;

A DIMS Unit Body may be compressed.

DIMS Units are framed by the transport layer. Each DIMS Unit has certain characteristics, signalled by the DIMS Unit Header.

There are DIMS Units used in redundant processing, and DIMS Units used in normal processing. Redundant DIMS Units, and DIMS Units marked as random-access points, are used in random access, tune-in, and error recovery; for a full description of their processing model, see subclause 5.8.

5.6.2 DIMS Unit Header

DIMS Unit Header is 1 byte long. The length of a DIMS Unit is the length of the DIMS Unit Body plus the length of the DIMS Unit Header. DIMS Unit lengths are carried by the transport layer.

The DIMS Unit Header has the following layout.

+—————+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
| X |C|P|D|I|M|S|
+—————+

Figure 5-3: DIMS Unit header

These fields have the following definitions:

S: is-Scene: when 1, indicates that the DIMS Unit contains a Scene Description as documented in subclause 5.4; when 0, indicates that the DIMS Unit contains one or more Scene Commands as documented in subclause 5.5.

M: is-RAP: when 1, indicates a Random Access Point; when 0, indicates a non-Random-access point.

I: is-redundant: when 0, indicates a main (normal processing) DIMS Unit; when 1, signals a redundant DIMS Unit.

D: redundant-exit: shall be 0 on DIMS Units with is-redundant==0; on DIMS Units with is-redundant==1, when 1, indicates that redundant processing is completed by this DIMS Unit, and normal processing should begin, and when 0, indicates that redundant processing should continue.

P: priority set to 1 indicates a high-priority unit; when set to 0 indicates a low-priority unit. A unit marked as low-priority indicates that if the unit, or any sequence of such low-priority units, is not processed by the terminal:

1. all succeeding DIMS Units can be decoded and operated on without error (e.g. their DOM updates do not depend on the possibly lost command(s).)

2. the visual and semantic nature of the scene is satisfactory to the content author.

3. The loss of those units does not require the terminal to enter into a tune-in or repair state.

Units fulfilling the above criteria should be marked as low-priority, and shall be marked as high-priority otherwise.

DIMS Units with is-redundant set to 1 should normally be marked as low-priority, to avoid their loss causing an un-needed entry into tune-in state when redundant and normal data are carried in the same transport.

C: compression: indicates the compression applied;
0 indicates no compression (textual format);
1 indicates that the content is compressed using the encoding signalled in stream setup.

X: reserved: shall be set to 0 and shall be ignored by the receiver

NOTE: The setting of the priority field is, due to point 2 above, partly at the discretion of the content creator. An example of a simple method of evaluating point 2 is to see if, when the next packet is received, the terminal state is identical to what it would have been if the DIMS Unit(s) had not been lost in the first place.

5.7 Timing model

DIMS inherits the timing model from [1] in its entirety. This section defines the timing of DIMS units.

DIMS units are associated with a media timestamp which marks

a) the time when the SVG scene is instantiated and the scene time resets to 0, for New Scenes, or

b) the time when DIMS units are applied and affect the scene, for other DIMS units.

The processing order for scene updates is the same as for script and event processing. The present document does not mandate any relative timing or processing order for DIMS units, scripts or events that shall be processed at the same scene time. DIMS Units from the same stream shall be processed in decoding order, i.e. sequence number order in RTP or order inside a sample in the 3GP file format.

In the main stream the SVG time has periodic resets to 0 on each New Scene (what SVG calls "document time" and is called here "SVG Scene Time"). The SVG scene time, and the media timestamps of the DIMS presentation, are related by a piecewise linear relationship, with discontinuities only at the New Scenes. Secondary streams are synchronized to the main stream using the normal mechanisms for media streams.

DIMS Units containing commands, with the same timestamp in the same stream, are applied "instantaneously" in scene time, that is, the scene time does not change while they are being applied.

DIMS units containing commands are applied atomically and have exclusive access to the scene tree during processing; only events and scripts directly resulting from the processing of the DIMS unit, are run.

5.8 Processing Model

A Scene Description is processed as a complete replacement for the current scene tree. That is, the entire DOM is discarded and replaced with the result of parsing the SVG element. All other DIMS Units retain (and possibly modify) the current scene tree.

All high-priority data units not marked as redundant shall be processed during normal decoding. All low-priority data units not marked as redundant should be processed during normal decoding. Data units marked as redundant should be ignored during normal processing. All data units marked as RAP are suitable tune-in points. When tuning-in to a stream, decoding shall begin by, at the latest, the first unit marked as RAP irrespective of the value of its is-redundant flag.

If a normal (non-redundant) random access point is identified during redundant processing or DRAP processing, the normal random access point should take precedence.

Commands that cannot be executed (e.g. they refer to a DOM node which does not exist) shall be ignored when in tune-in or redundant-processing. This condition should not arise in normal processing, and their handling in this state is not defined by the present document.

The following state diagram, and processing pseudo-code for each state, illustrate the states and the use of the various flags in the DIMS unit header, and comply with the mandatory and recommended processing requirements. The state diagram and pseudo-code, or better, should be implemented in DIMS clients.

In the state diagram and pseudo-code, the terminal may be processing a stream under one of three conditions:

a) normal processing, ‘normal’;

b) after tuning in, performing random access, or when loss is detected, ‘tune-in’;

c) while processing redundant DIMS units, ‘process-redundant’.

Tune-in state is entered under any of the following circumstances:

a) after opening a stream;

b) after performing random access;

c) after loss of a high-priority DIMS Unit in normal processing;

d) after loss of any DIMS Unit in redundant processing.

Figure 5-4: DIMS Client State Diagram

The following behaviour is performed for each DIMS Unit in each state, and then a state transition is performed as indicated by the state diagram.

Normal state:
if DIMS-Unit.is-redundant
then Discard(DIMS-Unit)
else Process(DIMS-Unit);

Tune-in state:
if DIMS-Unit.is-RAP
then Process(DIMS-Unit)
else Discard(DIMS-Unit);

Redundant-processing:
if ( DIMS-unit.is-redundant) ||
((not DIMS-Unit.is-redundant) && DIMS-unit.is-RAP)
then Process(DIMS-unit)
else Discard(DIMS-Unit);

Where this pseudo-code indicates that a DIMS Unit is processed, then if a Distributed Random Access Point (DRAP) is in process, elements required by the DRAP are extracted from this unit. If a DRAP is not in process, the DIMS Unit is processed as normal. If one of the DIMS units identified by units-required is a normal (non-redundant) random access point, DRAP processing should be abandoned, and that normal RAP processed in the usual way.

5.9 Random Access, Tune-in and Error Recovery

5.9.1 Introduction

Random access points in streams are either normal random access points or redundant random access points. Normal random access points are processed by terminals in all states. Redundant random access points should only be processed by terminals when performing random access, tune-in, or error recovery.

Random access points are indicated in the DIMS Unit header using the is-RAP flag. Redundant random access points have the is-Redundant flag set to 1; normal Random Access points have this flag set to 0.

5.9.2 Random Access Points in Primary Streams

A Random Access Point (normal or redundant RAP) in a primary stream shall either contain an entire scene (i.e. be a Scene Description) or the mechanism to build an entire scene (such as DRAP). When used, this scene becomes the current scene and replaces all previous data. There may be further DIMS Units with the same timestamp that modify the scene tree.

A redundant Random Access Point in a primary stream shall have the currentSceneTime attribute on the SVG element. Any following commands in subsequent DIMS Units with the same timestamp are processed at this time.

5.9.3 Random Access Points in Secondary Streams

A Random Access Point (normal or redundant RAP) in a secondary stream shall either contain an entire update (i.e. a series of commands) or the mechanism to build an entire update (such as DRAP). The command(s) provided set the scene (specifically, the portion of the scene managed by the secondary stream) into an appropriate state, whether the random access point is used for initial tune-in, or for error recovery.

NOTE: The secondary stream needs to be encoded in such a way that it does not matter which packets were lost or this is an initial tune-in or random access – the appropriate state is set. This would include removing any elements or attributes which should have been removed, etc. A simple way of encoding such a stream would be to only let updates in a secondary stream make modifications to a few nodes. Then this operation could be as simple as removing these few nodes and reinserting them, removing all potential errors.

5.9.4 Error Recovery

There are several error resilience mechanisms available in DIMS. Among these are:

– Priority: By separating essential and non-essential units one can determine if a loss need repair or not. This is described in subclause 7.3.1.

– Periodic Random Access Points (RAPs): Random Access Points can be placed periodically in a stream. In the case of error one can tune-in to the channel again.

– Separation of static and dynamic data. This can even increase the efficiency of Distributed Random Access Points.

A combination of these methods can be used.