diff options
author | Monty <xiphmont@xiph.org> | 2004-02-13 08:09:47 +0000 |
---|---|---|
committer | Monty <xiphmont@xiph.org> | 2004-02-13 08:09:47 +0000 |
commit | 464b956dc2ab2d09bcd2c9cd61f71df956f8b804 (patch) | |
tree | 69845245a55335c78bed889c35d55ad04bbc57ff | |
parent | 36f982e5c208a530bdee3c90b015dff17b6d2b48 (diff) | |
download | ogg-464b956dc2ab2d09bcd2c9cd61f71df956f8b804.tar.gz |
a few error corrections, clean up out-of-page notes. Still in progress.
git-svn-id: http://svn.xiph.org/trunk/ogg@5823 0101bb08-14d6-0310-b084-bc0e0c8e3800
-rw-r--r-- | doc/index.html | 1 | ||||
-rw-r--r-- | doc/ogg-multiplex.html | 46 |
2 files changed, 16 insertions, 31 deletions
diff --git a/doc/index.html b/doc/index.html index 9b4232b..b7ad768 100644 --- a/doc/index.html +++ b/doc/index.html @@ -1,3 +1,4 @@ <a href="oggstream.html">Ogg logical and physical bitstream overview</a><br> <a href="framing.html">Ogg logical bitstream framing</a><br> +<a href="ogg-multiplex.html">Ogg multi-stream multiplexing</a><br> diff --git a/doc/ogg-multiplex.html b/doc/ogg-multiplex.html index e6a8701..461745d 100644 --- a/doc/ogg-multiplex.html +++ b/doc/ogg-multiplex.html @@ -177,15 +177,26 @@ least the following complications:<p> for this reason, the point at which a video frame changes to the next frame is usually a strictly defined offset within the frme 'period'. That is, video at 50fps could just as easily define frame transitions -<.015, .035, .055...> as at <.00, .02, .04...> +<.015, .035, .055...> as at <.00, .02, .04...>. <li>frame rates often include drop-frames, leap-frames or other -rational-but-non-integer timings +rational-but-non-integer timings. <li>Decode must begin at a 'keyframe' or 'I frame'. Keyframes usually occur relatively seldom. </ul> +The first two points can be handled straightforwardly via the fact +that the codec has complete control mapping granule position to +absolute time; non-integer frame rates and offsets can be set in the +codec's initial header, and the rest is just arithmetic.<p> + +The third point appears trickier at first glance, but it too can be +handled through the granule position mapping mechanism. Here we +arrange the granule position in such a way that granule positions of +keyframes are easy to find. Divide the granule position <p> + + Can seek quickly to any keyframe without index @@ -253,27 +264,6 @@ continuous (such as Vorbis) or discontinuous (such as Writ). <h3>discontinuous granule position</h3> -it is able to definitively from the Ogg layer - - - - -Topics: - -Granpos mapping set by decoder - header decode (codec plugin) required to decode granpos - rationale: - must map back to absolute time - -Examples of granpos mappings - a) Vorbis (fixed rate) - b) Theora (bit-field for keyframe) - c) absolute time - -Continuous Stream Type -Discontinuous stream type - -MNG: variable framerate, possibly discontinuous; two code mappings? flushes around keyframes? RFC suggestion: repaginating or building a stream this way is nice but not required @@ -314,7 +304,6 @@ This excerpt discusses: <mau> ok, so what would be the strategy? seek to an arbitrary time, and wait for a keyframe? <mau> yeah, currently there is the hack in granulepos, right? -<mau> maybe just a macro? <danx0r> I've heard about it -- some sort of bitfield division <danx0r> lower bits are frames after a key <xiphmont> you can seek to a given location. the hack in granpos @@ -340,7 +329,7 @@ This excerpt discusses: <mau> it is also a good strategy, guess it depends on the player <xiphmont> rillian: the stream is set up to have a maximum keyframe spacing. Granpos is updated by a fixed amount at each keyframe. The - granpos is not [necessarily] monotonically increasing + granpos is not [necessarily] linearly increasing <Mike> true. <rillian> it's monotonic, but not (necessarily) linear <mau> xiphmont: so ideally the player would look at the granulepos and @@ -436,13 +425,9 @@ This excerpt discusses: <rillian> the concern as I understand was that there wasn't a page/packet that was specifically labelled 'this is a keyframe' at the ogg layer <xiphmont> rillian: same way vorbis does. Each frame does have a granpos, - they're just not monotonic. + they're just not linear. <rillian> s/wasn't/might not be/ <xiphmont> ah, yes there is. -<derf> Wait, they're not monotonic? -<xiphmont> no, just guaranteed to increase. -<derf> Oh... whew. -<derf> Different definitions of monotonic. <mau> sorry for being slow, but when you say "Frame" is this a packet, a page? <derf> I thought the encoding was @@ -455,7 +440,6 @@ This excerpt discusses: <mau> k, but if you put many packets in a page, then you do not have one for each, right? It is just a matter of counting up, and not allowing keyframes in the middle of a page? -<xiphmont> 'monotonically increasing' == 'increasing by one' <derf> mau: No. <derf> You can still put keyframes anywhere. <xiphmont> actually, my Ogg algos counts forward from previous page generally. |