ISOBMFF Presentation terms

[dwsinger]

The term "presentation" is used throughout the spec (~180 times) with different meanings. This is confusing. We propose to clarify it when possible and to replace it in other cases.

• "presentation"

When used standalone, it usually means "rendering" or "a set of related media" as in the introduction:

"The ISO Base Media File Format is designed to contain timed media information for a presentation in a flexible, extensible format that facilitates interchange, management, editing, and presentation of the media. This presentation may be ‘local’ to the system containing the presentation, or may be via a network or other stream delivery mechanism."

It is currently defined as follows:

"one or more motion sequences, possibly combined with audio"

This definition is outdated. We suggest replacing the definition with the simple:

"set of related media data "

We also suggest rephrasing the introduction which has too many 'presentation'.

• "presentation time" (60 occurrences)

There is no formal term in the definition section but the semantics of the 'tfra' box (8.8.10.3) says:

"The presentation time is the composition time of a sample, as adjusted by any edit list."

We suggest moving this text as a term definition in the definition clause.

We find also that:

"presentation times are in the movie timeline" (8.6.13.1 Segment Index Box definition)

which seems consistent with our understanding and the definition above. We suggest moving that text as a note in the definition clause. But, we find in Annex A, A.4:

" The exact presentation time (its time-stamp) of a sample is defined by summing the durations of the preceding samples."

which is confusing "time stamp" and "time" and more importantly "decoding time stamp" and "presentation time".

We suggest fixing that sentence as follows, by replacing:

"The exact presentation time (its time-stamp) of a sample is defined by summing the durations of the preceding samples."

with:

"The exact decoding time stamp of a sample is defined by summing the durations of the preceding samples."

Sometimes the term "movie presentation time" is used. We suggest removing "movie" (or always using it) as the "presentation time" is indeed in a "movie time".

The terms are "earliest presentation time" and "end presentation time" are used but don't seem ambiguous as they do consider the movie timeline (i.e. with edit list).

The different sections about RTP use the term of "presentation time stamp" with a different meaning:

• "presentation time-stamp" (RTP Packet Entry Format, 9.1.3.2)
• "presentation timestamp" (H.3.2 Compensation for unequal starting for position of received RTP streams)
• In H.4.4 and H.5.3 (duplicate text) "A presentation time on a timeline of the receiver clock is derived for each sample. If RTCP reception hint tracks are in use, the presentation time is the composition time of the sample on the movie timeline, also including clock drift correction as described in step 3 above. If RTCP reception hint tracks are not in use, the presentation time is directly the composition time of the sample on the movie timeline."

This is wrong and should be fixed.

• "presentation order" (9 occurrences) The term is not defined. When it is used, it is not related to the "presentation" (i.e. including edit list), it rather means: "order in which samples are with increasing composition times". Sometimes the term "output order" is used. Some other times the term "composition order" is used.

We suggest defining the term "composition order" (or "output order") as above and to use it consistently. Similarly, we suggest defining "decoding order" and using it consistently (versus "decode order").

• "presentation file" (4 occurrences) In 6.1.1, it is used to introduce the notion of external media data not stored in a main ISOBMFF file:

  " A presentation may be contained in several files. One file contains the metadata for the whole presentation, and is formatted to this specification. This file may also contain all the media data, whereupon the presentation is self-contained. The other files, if used, are not required to be formatted to this specification; they are used to contain media data, and may also contain unused media data, or other information. This specification concerns the structure of the presentation file only. The format of the media-data files is constrained by this specification only in that the media-data in the media files must be capable of description by the metadata defined here."

Similarly, in 11.2, it says:

" The main file containing the metadata may use other files to contain media-data. These other files may contain header declarations from a variety of standards, including this one. If such a secondary file has a metadata declaration set in it, that metadata is not part of the overall presentation. This allows small presentation files to be aggregated into a larger overall presentation by building new metadata and referencing the media-data, rather than copying it."

But in 6.1.2, the COR mixes this term with the notion of segment:

"A presentation file logically includes all its segments."

[dwsinger]

We believe this should be fixed. We suggest:

• removing the notion of presentation file

• and rewriting 6.1.1, 6.1.2 with the following text:

  "When represented according to the format defined in this part of the standard, a presentation may be stored in a single file or in multiple files, or it may even be delivered without the bytes being written in a file, for instance when streamed over a network and consumed on the fly. When split over multiple files, two different splitting options exist. In one option, one file contains the metadata for the whole presentation, and is formatted to this specification. The other files are not required to be formatted to this specification. They are used to contain media data, and may also contain unused media data, or other information. The format of these other files is constrained by this specification only in that the media data in them must be capable of description by the metadata defined in this specification. These other files may be ISO files, image files, or other formats. Only the media data itself, such as JPEG 2000 images, is stored in these other files; all timing and framing (position and size) information is in the ISO base media file, so the ancillary files are essentially free-format. If an ISO file contains hint tracks, the media tracks that reference the media data from which the hints were built shall remain in the file, even if the data within them is not directly referenced by the hint tracks; after deleting all hint tracks, the entire un-hinted presentation shall remain. Note that the media tracks may, however, refer to external files for their media data. In a second option, the media data is distributed over multiple files conformant to this specification. A first file contains some metadata valid for the whole presentation and possibly some media data and some metadata valid for a first part of the presentation. It also describes that additional files may be present. These additional files describe media and metadata for successive parts of the presentation. In more complex scenarios, the two options could be combined. In this specification, some boxes (called top-level boxes) are indicated as being at ‘file’ level, with the notation “Container: File”. This file corresponds to the single file when no other files are used; or when multiple files are used, to the virtual file formed by the concatenation of file containing the metadata for the first part of the presentation, with the other ISOBMFF compliant files in presentation order."

• "presentation metadata wrapper" (1 occurrence)

In "6.1.2 Object Structure", it says:

"The sequence of objects in the file shall contain exactly one presentation metadata wrapper (the MovieBox)."

We suggest replacing it with:

"The sequence of objects in the file shall contain exactly one MovieBox."

• "presentation information" (5 times)

The sentences using this term can easily be removed or the term replaced by "media information".

[cconcolato]

Just edited the above comments for readability.

[dwsinger]

This is improved in the 7th edition but more work is needed. a 'pull request' (edited file) would be appreciated.