[NUT-devel] Issues

[Rich Felker]

On Tue, Mar 07, 2006 at 03:18:54AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Mar 06, 2006 at 07:44:49PM -0500, Rich Felker wrote:
> > On Mon, Mar 06, 2006 at 05:52:12PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Mon, Mar 06, 2006 at 05:33:43PM +0100, Luca Barbato wrote:
> > > > Michael Niedermayer wrote:
> > > > > Hi
> > > > > 
> > > > > [...]
> > > > > 
> > > > 
> > > > Sorry to be me, but... nut is JUST for stored content, and before
> > > > someone start telling about http, well it is just serving a file over
> > > > tcp, it isn't streaming at all.
> > > > 
> > > > Could that make the issue die as it should long before? or is somebody
> > > > is really thinking about streaming NUT over udp making sure each packet
> > > > is contained in an udp packet?
> > > > 
> > > > Nut is good as backing store since it gives you all the informations you
> > > > need for streaming (using rtp, for example).
> > > 
> > > well, i am certainly not against droping all the "realtime streaming" stuff
> > > objections, comments anyone, rich?
> > 
> > Hmm, are you saying to completely remove nut-internal support for
> > variable info data embedded in the file, and instead have this at a
> > higher level transport layer, if at all? I would be strongly in favor
> > of that.
> 
> yes, though i would like to keep the option to add variable info in a later
> version of nut (so maybe say muxers MUST not change info but demuxers MUST
> accept it and use the last info packet they stumble across)

This is what I'm strongly against, since it requires a demuxer to read
unboundedly into the future in order to conform to the spec. It must
be possible to know when you've found all possible info that might be
relevant to a certain timespan so you can end the search. Otherwise
we're making a spec which is impossible to implement.

Rich