[MPlayer-dev-eng] NUT, what's left

[Rich Felker]

On Sat, Sep 17, 2005 at 11:09:17AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Sep 17, 2005 at 04:55:30AM -0400, Rich Felker wrote:
> > On Sat, Sep 17, 2005 at 10:40:26AM +0200, Michael Niedermayer wrote:
> > > [...]
> > > > > @@ -255,13 +254,11 @@
> > > > >  				other_stream_header
> > > > >  		}
> > > > >  		while(next_code != main_startcode){
> > > > > +			if(next_code == frame_startcode)
> > > > > +				sync_point
> > > > >  			if(next_code == info_startcode)
> > > > > -				info_packet
> > > > > -			else{
> > > > > -				if(next_code == frame_startcode)
> > > > > -					sync_point
> > > > > -				frame
> > > > > -			}
> > > > > +				info_startcode	f(64)
> > > > > +			frame
> > > > >  		}
> > > > 
> > > > I'm a bit confused about how this matches the below description of how
> > > > info frames are stored..
> > > 
> > > info packets are dead, the info_startcode can optionally be placed prior 
> > > to info frames
> > 
> > Now I'm confused. I thought global info frames were required to be
> > repeated with each set of headers, and right after the headers. Are
> > these now just normal stream packets with pts==0? I guess that works,
> > it just seems sort of weird... :)
> 
> yes, exactly, i wanted to avoid 2 different info "packets" in the hope
> that it would reduce demuxer and spec complexity

IMO it actually increases complexity, since the demuxer must consider
one type of info frame as "special" and demux it differently (preload
it at startup before any demuxing). Also it makes it difficult to
distinguish file-global info from local info starting at pts==0.

Rich