On Sat, Feb 11, 2006 at 11:23:09PM -0500, Rich Felker wrote:
On Sat, Feb 11, 2006 at 09:41:41PM +0200, Oded Shimon wrote:
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.
My thoughts as well on the issue... Ugly complication.
4. make 'N' implicit in frame codes (as in, no need to explicit specify it is invalid)
Agree.
Patch. Can I commit... On Sun, Feb 12, 2006 at 12:51:51AM +0100, Michael Niedermayer wrote:
On Sat, Feb 11, 2006 at 09:41:41PM +0200, Oded Shimon wrote:
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...
you dont need a single byte error for this to be usefull, if you loose 10kb in one chunk of a 100kb index you really want to be able to recover as much of the 90kb as you can ...
10kb of damage without another 2mb of damage in that whole area is highly unlikely... Especially with local storage...
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.
well, i dont care strongly about that, if you are against it fine then repeated frame == (keyframe && binary identical to last), it means 1 compare pass more for the demuxer if it wants to discard them (like when storing a network stream on reliable media)
Ok, issue closed...
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...
something crazy :) ive already suggested it long ago and its probably a stupid idea but it might mean big reduction of overhead and iam very curious how much space we could save with it ...
give each stream 2 byte sequences in the stream header (like codec_specific_data), one for keyframes one for non-key frames, then for each frame, put the correspong byte sequence before the frame before outputing it from the demuxer :)
It's weird.. It's the codec's job, not the container... Do we put it before ALL frames in the stream or add another stream flag (or nut flag?). Anyway, I suspect your savings will be about as much as your loss by adding checksums to syncpoints... I don't really consider it reduction in overhead, more like compression of data... I'm assuming you're refferring to silly mp3 and mpeg-4 startcodes?... - ods15