[theora-dev] a new proposal

[Michael Smith]

On Thursday 26 February 2004 18:14, Matt Zimmerman wrote:
> On Thu, Feb 26, 2004 at 04:24:59PM +1100, Michael Smith wrote:
> > On Thursday 26 February 2004 16:14, Matt Zimmerman wrote:
> > > On Wed, Feb 25, 2004 at 11:57:04PM -0500, Monty wrote:
> > > > ...sigh.  And the confusion spreads like wildfire.  We already have
> > > > perfect sync, Matt.
> > >
> > > Do you mind explaining briefly?  As of November, it was my
> > > understanding that Ogg could only hold media streams with One True Rate
> > > which held perfectly forever---no dropped frames, no DSP drift, etc. 
> > > Did things change since then, or does the state of the art still deal
> > > only with absolutely perfect streams?
> >
> > Ogg stamps each page (not quite per-packet, but per-packet stamps can be
> > calculated) with a "granulepos". This has a unique mapping to a time
> > value (which is codec dependent, but that doesn't really matter).
>
> But it doesn't have an accurate mapping to a time value, and that leads to
> the heart of the issue.  granulepos maps to a something like a sample
> number or a frame number, right?

It does have an accurate and unique mapping to a time value. Yes, for vorbis, 
granulepos is a sample number (granulepos can give anything at all, as long 
as it is uniquely mappable to a time value) - but that sample number directly 
gives a time value (using the sample rate).

>
> What if, instead of this hypothetical vorbis stream at 44.1kHz, I am
> recording from a PC sound card, so I have one which floats between, say
> 44000 and 44200.  Or I'm recording video, and every once in a while,
> something happens and I drop a frame.  Such is life.  Since the rate isn't
> constant for the entire stream, granulepos doesn't let you calculate an
> exact time offset.  It'll be off by a small percentage.

Well, if the rate isn't constant for the entire stream, then vorbis won't work 
properly - you'll have to correct for this in your encoder. This is not a 
problem with the ogg layer. Vorbis has only a constant sample rate (it has 
this in common with every other audio codec I've ever encountered).

However, if you assume that you have some reference clock which _is_ reliable, 
you can correct for your sound card drifting in your encoder. This isn't 
neccesarily simple - but the alternative (directly encoding absolute 
timestamps in the bitstream) requires the decoder to correct for this - the 
same amount of work, just moved to the decoder.

<p>>
> This probably doesn't present a significant problem for most Vorbis
> streams, which tend to be a few minutes long, and nobody really cares about
> the exact time offset anyway because they aren't synched to anything.  But
> in a video stream, after, say, an hour or two, that drift adds up to a time
> differential which is significant for A/V synchronization.

Well... if you have an inaccurate clock that you don't correct for, then of 
course this could be a problem. However, this is an encoder problem (not 
correcting) or a hardware problem (the drift to begin with) - NOT an ogg 
problem. Ogg allows the granulepos to represent whatever you want it to - if 
your codec wants to use absolute timestamps, then it can. 

<p>Mike

--- >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 'theora-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.