TransOgg Transport

From XiphWiki
Revision as of 03:15, 27 May 2010 by Xiphmont (talk | contribs) (Created page with '= Continuous vs. Discontinuous streams = For purposes of buffering and multiplexing, transport defines two stream types, 'continuous-time' and 'discontinuous time'. A continuou…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Continuous vs. Discontinuous streams

For purposes of buffering and multiplexing, transport defines two stream types, 'continuous-time' and 'discontinuous time'. A continuous-time stream contains no time or data gaps, with packets at regular predictable intervals. A discontinuous-time stream is more typically widely-spaced events with wide timing and data gaps between. Streams are declared continuous or discontinuous in the mandatory metadata.

Continuous time and discontinuous time streams are treated identically in mux and demux save two points:

 1) Only continuous-time streams are considered when filling buffers. 
 2) Pages in continuous-time streams are stamped by end-time (end
    time of last packet completed on a page.  If no packet is
    completed on a page, the page's timestamp shall be equal to the
    endtime of the packet begun on or spanning the page).  Pages from
    discontinuous-time streams are stamped by begin-time (begin time
    of first packet started on a page.  If no packet is started on a
    page, the page's timestamp shall be the begin time of the packet
    ending on or spanning the page). Note that
    continuous/discontinuous is not considered when interleaving
    pages in time order during multiplexing. This ensures proper
    delivery of discontinuous-time data when demuxing/buffering.
    (NUT documentation uses different terminology, but has a really
    good example that touches on this in the context of subtitles---
    go get it)

Page arrangement

No data may be inserted between transOgg pages in a transOgg stream. Data outside of of transOgg pages results in a loss-of-capture condition when reading the four bytes immediately following the end of a page does not yield the capture pattern.