[NUT-devel] Suggestions [PATCH]

[Michael Niedermayer]

Hi

On Wed, Mar 01, 2006 at 03:26:12PM +0200, Oded Shimon wrote:
> 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...)

i stongly object against info packet ordering rules which depend on the info
packet contents


[...]

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

disagree

[...]

-- 
Michael