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