[NUT-devel] Suggestions [PATCH]

[Rich Felker]

On Wed, Mar 01, 2006 at 03:25:35PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Mar 01, 2006 at 09:00:49AM -0500, Rich Felker wrote:
> > On Wed, Mar 01, 2006 at 02:48:20PM +0100, Michael Niedermayer wrote:
> > > 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
> > 
> > And I'm strongly against arbitrary ordering of info packets for the
> > reason I described in the other email: finding the info that's
> > relevant to local content is O(totalfilesize). In fact with a live
> > stream with no end, you _never_ know you have the correct info!
> 
> the muxer must place the info sanely,

This is exactly what I want in the requirements.

> the demuxer should NEVER go and search
> for info packets, they must be placed where needed

After they're relevant is never where they're needed. My rule was just
describing how to put them where they're needed.

Rich