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

[Oded Shimon]

On Sat, Sep 17, 2005 at 11:42:46AM -0400, Rich Felker wrote:
> 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.

I think we should have a compromise - both info packets (with an info 
startcode and packet header), and info streams, which never have a 
startcode and conform exactly as in this patch.

This is most sane imo. the global info packets have no pts, can be repeated 
easily, etc.
the info frames have an associated pts, and index, etc.

if we do agree on this, we should also make it a requirement that info 
packets can only ever comes after the headers! i.e. they'd be identical to 
stream headers - only after the header, and repeated together with the 
header. although come to think of it, the repeating should not be manditory 
because it could be very big (ugly png cover image or whatever).

- ods15