[theora-dev] Timestamps...

[illiminable]

----- Original Message -----
From: "Michael Smith" <msmith at xiph.org>
To: <theora-dev at xiph.org>
Sent: Friday, May 14, 2004 4:05 PM
Subject: Re: [theora-dev] Timestamps...

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

*looks back at code*... oh yeah... whoops :)

Still 0.2% is still not much !

> 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

Depends on the codec really...

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

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.

Zen.

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