[NUT-devel] Suggestions [PATCH]

[Rich Felker]

On Wed, Mar 01, 2006 at 01:50:44PM +0100, Michael Niedermayer wrote:
> > 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

I still favor having info streams separate for the reasons I explained
in the other email.

> > > @@ -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?

This flag pertains to the NUT structure, not the frame contents, so it
belongs in the other flags if at all.

Personally I don't like this approach and prefer the old way of doing
syncpoint checksums as long as you can make it sufficiently extensible
to your liking.

> > >      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

Why is it 2* ? Why not just max_distance?

> > solution is that it worked even after a seek or damage, it required no 
> > additional variable or context.
> > Also, does the syncpoint rule of max_pts_distance still apply? or is it 
> > just this checksum rule.
> 
> the syncpoint max_pts_distance rule doesnt apply anymore

Yes, and IMO that's problematic.. The rule was very simple and good.

> > >  checksum
> > >      crc32 checksum
> > >      checksum is calculated for the area pointed to by forward_ptr not
> > >      including the checksum itself (from first byte after the
> > >      forward_ptr until last byte before the checksum).
> > 
> > You should probably mention what area the checksum of frame headers 
> > cover...
> 
> ok

Is a checksum of 1 byte really useful? IMO not. Considering that with
your proposal a frame header for a 1-meg packet could still be just 1
byte (easy with CBR), this seems like it will not work. This is one
reason I prefer the method of combining with syncpoints.

Rich