[NUT-devel] Welcome...

[Rich Felker]

[resent due to the 100l reply-to issue...]

On Sat, Feb 11, 2006 at 09:41:41PM +0200, Oded Shimon wrote:
> hut... hut... is this thing on?
> OK, mailing list is working :)
> 
> For all your anonymous enjoyment, you can get latest libnut and nututuils 
> from:
> svn checkout svn://213.144.138.186/nut/trunk
> 
> Make sure to read README...
> 
> You'll also see all commits in this ml..
> 
> 
> On to buisness... Spec:
> 
> 1. Split index
> The only big problem I see is deciding where to split it, and I doubt if 
> even libnut will support this. It's also weird in regards to index_ptr. I 
> vote against this... If it's local storage, you probably have a big damage 
> chunk, not a single byte one...

I'm against split-index. It's unnecessary complication to protect
_redundant_ data. The index contains no information of it's own, it's
all derived data stored in a common place for easy access. In the case
of a file with corruption in the index, you can just build a new index
if you really need one. IMO if just the index is damaged, you should
be _glad_ that the damage was isolated to the index and either rebuild
it or be happy with slightly slow seeking.

> 2. Frame repetition
> Well, is there anything to really do about this? I can't think of any way a 
> flag would be useful to the demuxer or player, you can just repeat the 
> frame as is, maybe let the codec layer deal with it.

I'd need to think about it some more. I really don't like frame
repetition at all...

> 3. convert_ts overflow
> Uhhh... 120 years otta be enough for everybody.

So should 640kb :)
Or, a more relevant example: 32bit time_t should be enough for
everybody...
Or, ... 2 digit years should be enough for everybody!

However, this is NOT a bug in nut. The convert_ts code in the spec is
_informative_, not normative, i.e. it's a recommended implementation
that works for the range of numbers likely to be encountered.
Implementations needing higher ts range can use different algorithms
as long as the result is the same. However the spec should be changed
slightly to make this clear.

> 4. make 'N' implicit in frame codes (as in, no need to explicit specify it 
> is invalid)

Agree.

> Anything else? These are truely the last issues I'm aware of, as far as I'm 
> concerned we can (finally) finalize spec... If anybody has anything, say it 
> now...

:)

Rich