[theora-dev] a new proposal
msmith at xiph.org
Sun Feb 29 17:07:03 PST 2004
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.
> 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.
--- >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.
More information about the Theora-dev