[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