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

[Michael Niedermayer]

Hi

On Wed, Nov 22, 2006 at 03:13:27AM +0200, Oded Shimon wrote:
> 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 ...

additional note, i dont know if there really is a problem in the rtp case
as i dont know rtp well enough, maybe the timestamps have few enough bits
so this wouldnt be a problem but still a "choose a sane value" is not a
good way to specify the valid range of something ...


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

please add a note to the spec sying that people MUST NOT use timestamps
from mpeg* blindly while transcoding as mpeg can have timestamp
discontinuities ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is