[NUT-devel] Suggestions [PATCH]

[Oded Shimon]

On Wed, Mar 01, 2006 at 01:50:44PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 01, 2006 at 06:15:44AM +0200, Oded Shimon wrote:
> > >          if (!eof) while(next_code != main_startcode){
> > > -            if(next_code == syncpoint_startcode)
> > > -                syncpoint
> > > +            if(next_code == syncpoint_startcode){
> > > +                prolog, syncpoint, epilog
> > > +            }
> > >              frame
> > > +            reserved_headers
> > >          }
> > >      }
> > 
> > Does this mean info packets can only come after headers?... What if the 
> > headers are large and the radio station wants to switch songs, repeat the 
> > entire headers and then the info packets?
> 
> the current nut has this limit too, iam perfectly fine with removing that,
> but IIRC rich at some point in the past wanted info only after stream headers
> or something like that

The current NUT has info streams and info packets always apply globally, so 
it makes sense in current NUT...
Hmm, I do suggest a rule "all info packets with chapter_id>=0 MUST come 
after main headers" (and not arbitrarily between frames...)

> > > @@ -476,12 +500,15 @@
> > >        1  is_key             if set, frame is keyframe
> > >        2  end_of_relevance   if set, stream has no relevance on
> > >                              presentation. (EOR)
> > > +      4  has_checksum       if set then the frame header contains a checksum
> > 
> > Maybe this should be a NUT-flag?
> 
> NUT-flag?

There are stream flags and nut flags. nut flags are 'msb coded size', 
'invalid frame code' and 'coded stream flags'. The checksum flag sounds 
like a nut flag. (stream flags go on to the caller api, nut flags stay 
within the nut demuxer)

> > >      EOR frames MUST be zero-length and must be set keyframe.
> > >      All streams SHOULD end with EOR, where the pts of the EOR indicates the
> > >      end presentation time of the final frame.
> > >      An EOR set stream is unset by the first content frames.
> > >      EOR can only be unset in streams with zero decode_delay .
> > > +    has_checksum must be set if the frame is larger then 64kb or its
> > 
> > 2*max_distance ?
> 
> ok

Actually, I'd go even further to suggest this as a per stream setting...

> > > @@ -729,21 +743,30 @@
> > >  If an index is written anywhere in the file, it MUST be written at end of
> > >  file as well.
> > >  
> > > +Each index packet SHOULD be <4kb, that way a demuxer can simply:
> > 
> > This is extremely hard to enforce, the index has 2 parts, the syncpoint 
> > positions and the keyframe pts stuff. The keyframe pts is usually pretty 
> > small so you could just stop when you reach 4kb when writing syncpoint 
> > positions, and hope that the other part doesn't grow past 4kb...
> 
> for(i=0; i<n; i+=step){
>     while(build index(i, step, 4kb))
>         step>>=1;
>     write out
> }
> 
> build & write out can trivially be replaced by write & seek back within an IO
> buffer

Ah, ok that's good, didn't think of that. It still leave the problem of 
reading index (and truely, I dislike the added complexity for the 
questionable gain.)
You said this "simplifies" building the index, because forward_ptr is 
unknown, and a 2 pass solution is messy. You solution for building the 
index requires building it MANY times.. Although I don't see either actions 
as messy at all, the first pass could be done using a "bit bucket" memory 
buffer, and the second pass would be to file out. though you might as well 
build it in memory alltogether, this is only for the muxer, nobody cares 
about 80kb memory usage for muxing...

The 2 big problems I still have with this new index - index_ptr, and 
raising complexity of utility that copies index to begginning of file. Yes, 
both are rather "rediculous" and solvable issues, but WHY have these issues 
at all... We already disucssed that the likelyhood of loosing a little data 
in the index without loosing all of it is very little. Rich gave up his 
"advanced syncpoints" because they raised complexity greatly for very 
questionable gain...
Index repetition is very useful, because you can have the index in 2 edges 
of the file, but IMO index splitting is hardly useful at all, you might as 
well just repeat the index twice in the end.
And, I'll continue being redundant here, in noting that loosing the index 
is no great trajedy!... Even in cdroms, seeking without index was just 
fine! Admittedly slightly slower, but still in the vecinity of ~1 second 
per seek. Is this really worth it.

- ods15