[Theora-dev] Resyncing cut streams...
Timothy B. Terriberry
tterribe at vt.edu
Thu Jan 6 16:45:07 PST 2005
> That's not neccesarily true, though, even for "normal" streams. A
> vorbis stream, for instance, may have a logically non-zero initial
> offset, which vorbis uses to indicate that the codec should discard
> the first N samples of the packet (as part of the sample-precise
> support vorbis has).
Correct me if I'm wrong, but I thought it was a _negative_ offset
applied to the granule position of the _end_ of the first page. This
effectively moves the granule position "0" into the middle of that page,
which is what indicates how many samples to drop. So the start of the
stream is still at granule zero.
> > > d) The big buffer solution.
> > > ie Buffer everything up letting all the renderers run dry, and
> > > hope we eventually get something that has a time stamp (which is
> > > not gauranteed) and then jam all the collected data (ie 1+ seconds
> > > of raw audio and video) out in one big chunk.
I know this came up on IRC, but I want to reiterate here that I believe
you _are_ guaranteed to get a timestamp, as soon as you find a page on
which at least one (non-header) packet ends.
(Pedantically, it's conceivable that there might be none, but that also
means you have no complete packets, so it's not a big deal)
Streams which do not properly timestamp pages on which packets end are
broken. Maybe you want to make some effort to support them, but I
wouldn't bend over backwards. It should not be a common case.
More information about the Theora-dev