[NUT-devel] Welcome...

[Oded Shimon]

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
-------------- next part --------------
Index: DOCS/tech/mpcf.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
retrieving revision 1.103
diff -u -r1.103 mpcf.txt
--- DOCS/tech/mpcf.txt	11 Feb 2006 09:56:49 -0000	1.103
+++ DOCS/tech/mpcf.txt	12 Feb 2006 05:30:11 -0000
@@ -151,6 +151,11 @@
             tmp_reserved[i]             v
         }
         for(j=0; j<count && i<256; j++, i++){
+            if (i == 'N') {
+                flags[i]= 4;
+                j--;
+                continue;
+            }
             flags[i]= tmp_flag;
             stream_flags[i]= tmp_sflag;
             stream_id_plus1[i]= tmp_stream;
@@ -469,8 +474,6 @@
       2  more_flags       if set, stream control flags are at frame header.
       4  invalid          if set, frame_code is invalid.
 
-    frame_code=78 ('N') MUST have flags=64
-
 stream_flags
     stream_flags is "stream_flags[frame_code] ^ coded_stream_flags"