ContainerFormatMappingGuidelines

From Diracvideo

Please bear the following in mind when writing a new mapping to encapsulate Dirac in some container format. These are not hard and fast rules -- some may not apply depending upon the limitations of the muxing/container format.

This document idealises the muxing/container format by referring to muxing units. Quite what they map to needs some thought. For example in MPEG2-1 transport streams, the muxing unit is a PES packet, not a transport stream packet.

[edit] Specification nomenclature

Avoid confusion with old deprecated terminology:

• Do not call anything an 'access unit'.
• Do not call anything a 'parse unit'

Avoid the use of MPEG-2 terms:

• B and P picture.
  Dirac isn't restricted to such a limited prediction structure.

[edit] On random access

The Intra Frame immediately following a sequence header is the only place in the Dirac bytestream that provides the guarantee that all frames with a picture_number greater than the intra frame are decodeable

Ie, encountering an Intra frame does not guarantee decoding from that point.

It is not advisable for a demuxer to solve any decoding dependencies to work out the earliest decodable frame; the solution may diverge and not terminate.

Some container formats cannot handle frame reordering around a seek point. In this case, Dirac sequence headers + intra pictures followed by pictures with a lower picture number must not be considered seek points.

[edit] General container guidelines

1. A Dirac data unit should not span muxing units. This only tends to increase complexity and work for little gain.
2. Dirac data units should be aggregated into muxing units such that muxing units contain:
   zero or more non-picture Dirac data units, followed by a single:
   • • Dirac picture data unit,
   • OR
     • Dirac end-of-sequence data unit
3. The temporal ordering of data within the Dirac bytestream must never be changed
4. No Dirac data unit may be discarded
   Why?
   • There is no non-essential metadata contained within a Dirac bytestream.
     It can therefore be assumed that everything else is essential.
   • Yes, even any form of padding or private data is essential. An encoder will not put it in there without good reason; it is impossible for a muxer to second-guess the operators decisions. (eg, padding may exist for CBR constraints). If the user wishes padding data to be removed, let it be explicitly done.
   • Yes, this includes EndOfStream Dirac data units. They allow changes of immutable stream parameters (which can occur mid stream)