Difference between revisions of "OggText"

From XiphWiki
Jump to: navigation, search
(added linguistic markup)
Line 162: Line 162:
The EOS page ends a text codec stream. It is an empty packet because all the information of the codec is encapsulated in the earlier data pages.
[[Category:Ogg Mappings]]

Revision as of 03:03, 12 November 2008



Prominent examples of such text codecs are:

  • CC: closed captions (for the deaf)
  • SUB: subtitles
  • TAD: textual audio descriptions (for the blind)
  • KTV: karaoke
  • TIK: ticker text
  • AR: active regions
  • NB: metadata & semantic annotations
  • TRX: transcripts / scripts
  • LRC: lyrics
  • LIN: linguistic markup



Codecs with existing mappings are:

  • CMML
  • Kate

Bitstream Format



When these packets are multiplexed into Ogg, they are mapped to Ogg pages. For text codecs, there is a sequence of header pages, a sequence of data pages, and an EOS page, which finishes the stream. The pages have to be ordered non-decreasing with time. No data can come after the EOS page.

Header pages

Header packets are a sequence of:

  • one ident header, which identifies the codec
  • one (optional) vorbis-comment header
  • one or more secondary header packets that are codec specific



The format of the ident header

 0               1               2               3              |
| Version major                 | Version minor                 | 8-11


The following packtypes are distinguished:

0x80 ID header (BOS page)
0x81 vorbis-comment header (optional)
0x00 text data (including optional motions and overrides)
0x01 keepalive
0x7f end page (EOS page)


In all header pages, the packtype is followed by the text codec magic from byte offset 1 to byte offset 3 ("txt"). The succeeding four bytes are to be used by the text codec to identify itself.



Version major & minor are fields that are used by the text codec to define the version of its mapping.

The format of the Skeleton Fisbone

Text codecs are required to be used in conjunction with Ogg Skeleton.

The following fields are defined in the Fisbone header for a text codec:

  • granulerate numerator & denominator
  • granuleshift
  • number of header pages/packets
    • directionality of this text is implicitly given by the charset


The granule position format


The solution is to seek forward to the next text codec page, which then has information on the first text codec page that is still active. Then you can seek back to this page and seek forward to the previous page to gather all the pages that are still active.

For this, the granulepos is being segmented into two parts, where one part signifies the insertion time of the current page, and the other part contains the granulepos of the first page with text codec data that is still active.

| granulepos prev | current time    |


The default granule shift used for text codecs is 32, which halfs the granule position to allow for the backwards pointer.

Data pages


For text codecs, each data packet is mapped onto a single Ogg data page with all its content. This is possible because generally text codec packets are rather small. The insertion time is encoded in the granule_pos of the Ogg page.


Thus, the following data pages can be distinguished:

  • ordinary data pages
  • keep-alive pages

The format of a Data page

 0               1               2               3              |
| Start Time                                                    | 4-7
| Start Time (continued)                                        | 8-11
| End Time                                                      | 12-15
| End Time (continued)                                          | 16-19
| Codec Data ...                                                | 20-...


Therefore, the duration that a data page is on screen is not encoded in the encapsulation format. In CMML, the duration was set by creating pages that would end previously active pages. Here, instead, we decide to encode the duration directly into the data page and make all such calculations from the data that is stored at the beginning of the data packet.

In essence, we would only require to put the end time into the data page. However, for completeness, we add both, the start and the end time. Both are specified in seconds from the start of the video.

After that, the data of the text codec will be encapsulated. This would preferrably be without a repetition of the start and end time. For example, for srt, it makes sense to include just the subtitle text as codec data.

EOS page
