[theora-dev] Timestamps...

[illiminable]

----- Original Message -----
From: "illiminable" <ogg at illiminable.com>
To: <theora-dev at xiph.org>
Sent: Saturday, May 15, 2004 8:08 AM
Subject: Re: [theora-dev] Timestamps...

<p>>
> ----- Original Message -----
> From: "Ralph Giles" <giles at xiph.org>
> To: <theora-dev at xiph.org>
> Sent: Saturday, May 15, 2004 1:10 AM
> Subject: Re: [theora-dev] Timestamps...
>
>
> > On Fri, May 14, 2004 at 04:23:53PM +0800, illiminable wrote:
> >
> > > The conversion of time representations is just a simple calculation...
> The
> > > decode the packets options is a far more complicated operation, and
> either
> > > requires the demux knowing how to decode itself or being able to call
> the
> > > decoder to figure it out. Which means processing the page... certainly
> any
> > > simple calculation will be far more efficient that potentially reading
> and
> > > processing a whole page of data.
> >
> > Sounds like you're arguing for real-time granulepos again.
> >
> No... it that would be nice, but it doesn't really matter, any granule pos
> scheme is fine.
>
> > If you know the media is 'continuous' the start time of the page is the
> end-
> > time of the previous page. Having an extra granulepos field on each page
> > doesn't help you at all here. Is there any problem with just applying
this
> > abstraction to 'discontinuous' streams in DirectShow? I guess so if you
> > really need per-packet start and end timestamps.
> >
>
> It does help because it means you don't have to search for a pervious page
> in every logical stream. At the moment, you have to find the page you want
> to start at, then seek backwards to ensure you go back far enough that you
> find the previous page of every stream, in order to find the relative
start
> times of each stream at your desired start position.
>
> Yes... start packet times are pretty much essential for the renderer.
>

And one thing i forgot to add, is that the end time of the previous page, is
not necessarily the start time of the first complete packet on the next
page.

If the previous page has an incomplete packet, the endtime on this page, is
the end time for the second last packet on the page. Which means that the
start time of the first comlpete packet on the desired page is not the same
as the end time on the previous page.

This means that instead of provding a continuous stream of data from a
particular point, you would have to go back to the previous page store the
fragment of the last packet in any stream that has one. Now at your desired
start position, the demuxer has to hold this partial packet, start demuxing
the desired page but don't pass it through the graph as is normal. Stick the
first packet back together after demuxing the page, then push these buffered
packets through, then continue normal streaming.

> Zen.
>
> >  -r
> > --- >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.