[NUT-devel] Suggestions [PATCH]

[Michael Niedermayer]

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, the demuxer should NEVER go and search
for info packets, they must be placed where needed

[...]
-- 
Michael