theora dev - May 2004 - Timestamps...

Since we've been debating the merits of start or end timestamping... i'm
curious why the page doesn't have both stamps ?

That would solve the problems for all parties wouldn't it ?

It's not like the overhead is huge... less than 0.1%... so on the average
audio file thats 5 megs.... it's a 5k increase, which pretty much
insignificant. Even on a 1gig video file it's only another 5 megs.

Both stamps are usefull for their own things, and it would let all
implementations be more efficient.

Also the other thing i've been thinking about is the size of the timestamp
field being only 32 bits... this means a limit of ~27 hours of audio at
44100. And there are certainly other applications (say a file with the years
stock prices, earthquake data for the year etc)... there are times when
you'd want to manitain a continuous single logical stream for long
durations. In order to do this currently you'd have to somehow denote
someway to indicate where the granule pos resets, which would also totally
mess with all the seeking algorithms.

Zen.

<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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Friday 14 May 2004 17:59, illiminable wrote:
> Since we've been debating the merits of start or end timestamping...
i'm
> curious why the page doesn't have both stamps ?
>
> That would solve the problems for all parties wouldn't it ?
>
> It's not like the overhead is huge... less than 0.1%... so on the
average
> audio file thats 5 megs.... it's a 5k increase, which pretty much
> insignificant. Even on a 1gig video file it's only another 5 megs.
>
> Both stamps are usefull for their own things, and it would let all
> implementations be more efficient.
>
> Also the other thing i've been thinking about is the size of the
timestamp
> field being only 32 bits... this means a limit of ~27 hours of audio at
> 44100. And there are certainly other applications (say a file with the
> years stock prices, earthquake data for the year etc)... there are times
> when you'd want to manitain a continuous single logical stream for long
> durations. In order to do this currently you'd have to somehow denote
> someway to indicate where the granule pos resets, which would also totally
> mess with all the seeking algorithms.
>
granulepos is 64 bits, not 32. 

This presumably means your overhead calculations are off too. Regardless: the 
reason not to require both is that it's not useful - given one, the other
can
always be calculated (from the packets in the page - in a codec-specific way, 
of course). The calculations aren't complex or heavy-weight either, so the 
'efficiency' argument doesn't seem (to me) to hold much water - you
still
need to convert your timestamps to the 'native' representation of your 
framework, so you also can't argue that this means you can avoid 
codec-specific calculations at this stage.

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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

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

<p>>
> ----- Original Message -----
> From: "Ralph Giles" <giles@xiph.org>
> To: <theora-dev@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@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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.