[vorbis-dev] granulepos start/end revisited

[André Pang]

Hi all,

I noticed the following Subversion commit today:

   r6719 | xiphmont | 2004-05-18 16:04:53 +1000 (Tue, 18 May 2004) | 11 
lines

   Updated doc to reflect current proposal...

   Not as much a proposal at this point actually; this is the way I'm now
   implementing it.  Although we're still in the 'RFC'/'look for horrible
   lossage' stage, this is close to being set in stone unless we find
   something horribly wrong with it.

   Doc is still very light on detailed rationale and examples; I'd like
   to subcontract that part of the writing and get on with code.

I'm a bit concerned about some of the multiplexing changes, 
specifically these paragraphs:

     A granule position represents the instantaneous time location 
between two pages. However, continuous streams and discontinuous 
streams differ on whether the granulepos represents the end-time of the 
data on a page or the start-time. Continuous streams are 'end-time' 
encoded; the granulepos represents the point in time immediately after 
the last data decoded from a page. Discontinuous streams are 
'start-time' encoded; the granulepos represents the point in time of 
the first data decoded from the page.

     An Ogg stream type is declared continuous or discontinuous by its 
codec. A given codec may support both continuous and discontinuous 
operation so long as any given logical stream is continuous or 
discontinuous for its entirety and the codec is able to ascertain (and 
inform the Ogg layer) as to which after decoding the initial stream 
header. The majority of codecs will always be continuous (such as 
Vorbis) or discontinuous (such as Writ).

     Start- and end-time encoding do not affect multiplexing sort-order; 
pages are still sorted by the absolute time a given granulepos maps to 
regardless of whether that granulepos prepresents start- or end-time.

A simple question (with a complex answer, no doubt): what's the 
rationale for having a start-time encoded granulepos?  It adds (1) 
another dependency, and (2) the need for mode core to handle both start 
times and end times, which will also touch many parts of Ogg and 
possibly affect the code base of the codecs as well.

To frame the question another way, what's wrong with the current 
end-time granulepos scheme?  I've read through all the discussions and 
IRC meeting logs, and still don't understand the necessity for it.

Thanks,

<p>
-- 
% Andre Pang : trust.in.love.to.save

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.