[NUT-devel] Info packets in NUT stream (spec bugs?)

[Oded Shimon]

On Tue, Nov 21, 2006 at 10:35:57PM +0100, Michael Niedermayer wrote:
> On Tue, Nov 21, 2006 at 02:32:14PM -0500, Rich Felker wrote:
> > On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
> > > what is excessively large? whats idiotic? thats not a good way to specify
> > > the valid range of a value
> > > >32bit is idiotic for many people iam pretty sure, still its not enough
> > > if your input data is in nanosecond precission ...
> > > 
> > > and its neither reasonable to assume that everyone has to spend an hour
> > > per field to guess what range of values would have to be supported to handle
> > > all non idiotic cases
> > 
> > My idea is that what's idiotic changes with time. That's why we use
> > vlc rather than fixed-size fields. Unlike other potential areas of
> > abuse in the spec, I don't see any realistic issue with people
> > intentionally choosing initial timestamps that will cause trouble with
> > some implementations. Generally the only things people would choose
> > for starting timestamps would be 0, the end timestamp of another file,
> > or the current unix time (seconds since the epoch). All of these will
> > fit ok in 64bit as long as a sane timebase is used.
> 
> for rtp the start timestamp is recommanded to be random() IIRC and for
> transcoding people might choose to keep the start timestamp also when
> taking some seconds since x and converting that to a "insane" timebase
> problems will happen ...

Just wanted to know one more possible scenario for this - stupid people 
transcoding directly with pts from mpeg (i've seen mpegs start at 
timestamps of 24352...)

- ods15