[theora-dev] Granule Pos of start of page...

[illiminable]

----- Original Message -----
From: "Conrad Parker" <conrad at metadecks.org>
To: <theora-dev at xiph.org>
Sent: Wednesday, May 05, 2004 5:18 PM
Subject: Re: [theora-dev] Granule Pos of start of page...

<p>> Hi Zen,
>
> For starters, if you want to get proper a/v sync from an exact timepoint,
> you need to have decoded a few packets preceeding that timepoint. For
> vorbis, you need to roll back 2 packets to accomodate the overlap-add.
> For theora, you need to roll back to the preceeding keyframe. Once you've
> done that, you must feed the encoded data into your decoder. You can throw
> away the frames of audio and video generated prior to the target
timepoint,
> but you have to pass the packet data through the decoder in order for the
> decode state to get set up properly.
>
> The reason I mention that first is that what you *don't* want is to
somehow
> byte-seek to the exact packet that "contains" the target timepoint, and
> then start reading and expect the a/v to decode perfectly and in sync.
>

Hmmm... ok... i guess that's what that preroll function i've been ignoring
is for :)

Because every time directshow seeks it effectively makes all samples
relative to the seek position... ie sample time 0 is the seek point. What i
think i've been doing wrong is instead of letting absolute times propagate
through the graph and subtracting the seek point at the last minute and
marking any negative values as preroll samples, i've just been setting all
the reference times to zero and starting to count again.

> And, before someone else jumps in with the idea of making the granulepos
> indicate the start-time of the packet, no, that doesn't help at all and
> would only make seeking more inefficient :)
>

Could you give me some more detail about why this is so ? I'm just not
getting it ! I don't see how in terms of seeking to some point it really
matters if it's the start or the end time. If anything from my limited
experience it makes it less efficient (though perhaps that's due to the fact
that directshow must have start times for samples, so i'm forced to
calculate them regardless). In fact all my seeking works by creating a
mapping of the byte position of the start of the page of the reference
stream to the previous page in that streams granule pos and rounding down.

So when i seek for a time, i get the start of the page that contains that
time. Or now that you mention i need some preroll i will map to the start of
a page x previous to the one i want such that the mapped page will be at
least one keyframe and 2 vorbis packets prior to what i want. This way you
never have to seek backwards and the demux is always in sync and never has
to byte scan for capture patterns.

What i don't get is how seeking (be it by equidistant bisection,
non-equidistant approximating bisection, or by seek table mapping) benefits
by having one scheme or the other ? To be sure you have the right place you
have to narrow your search space to a single page range to know your
bisection has the best guess. So how is narrowing it on end times then
choosing the upper bound any different from narrowing on start times and
choosing the lower bound ?

>From what you mention... if anything you want to find a point before, and
surely start time stamp makes that easier ?

Also the whole idea of seeking backwards seems to be rather inneficient...
seeking forwards is fast because from the header you can find the page
length and jump straight to the next page (scanning at most 282 bytes), but
seeking backwards you byte scan on average half the average page size and in
the worst case about 65,000 bytes, trying to sync to a capture pattern.

I must be missing something...

> So, the right thing to do is:
> 0. ensure that your decoders always tell your a/v engine whatever
>    timestamps they see while reading, as well as adding on the
>    number of generated frames
> 1. seek to about where you want to be, by granulepos markers.
> 2. scan back by a bit. Either just seek back some random amount,
>    (you're close enough already that you might as well just
>    resync a few K back or so :) or scan back through the packets.
> 3. start reading and decoding, throwing away the generated frames.
>    a few timestamps will pass by, you'll passed a keyframe and at
>    least 2 vorbis frames ...
> 4. once you figure you're at the correct playback time, start
>    actually sending the frames onwards.
>
> You *need* to do that to actually get the right a/v data. The two streams
> aren't frame clocked, they have different granulerates, and they have
> different prebuffering requirements. But all you should need to do is
> give the a/v engine the decoded data with timestamps -- it's its job to
> actually render the decoded streams synchronously.
>

OK... thanks, that explains a lot. Does theora need some kind of "reset" or
something or will it handle discontinuous data coming through after a seek ?

Thanks again,

Zen.

> good luck :)
>
> Conrad.
>
> On Wed, May 05, 2004 at 04:32:28PM +0800, illiminable wrote:
> > OK... i've come across a problem trying to get the granule pos of the
start
> > of the page... it's not so crucial with single stream ogg files... but
now
> > that i have theora+vorbis in a file, i'm finding that when i seek to a
> > position, i have no way to determine the relative offsets of the
different
> > streams at the new seek point and hence the av is out of sync.
> >
> > So given a page, is it possible to determine the start time... or do i
have
> > to code this separately for each codec and decode the page determine the
> > quantity of data and then subtract it ? Or else scan backwards looking
for
> > each of the other streams and use a previous page endpoint as a start
point
> > for the page i actaully want to know about.
> >
> > The problem with using previous pages is that if the page you want to
know
> > about has a part of a packet from the previous page... then it's
actually
> > the last packet on the previous page that starts at that time.
> >
> > Is there an easy solution for this ?
> >
> > Cheers,
> >
> > Zen
> >
> >
> > --- >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.
> --- >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.
>
>
>

<p>--- >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.