[NUT-devel] Issues
Rich Felker
dalias at aerifal.cx
Wed Mar 8 09:56:45 CET 2006
On Tue, Mar 07, 2006 at 10:59:50PM +0100, Michael Niedermayer wrote:
> Hi
>
> On Tue, Mar 07, 2006 at 07:23:05PM +0200, Jan Knutar wrote:
> > On Tuesday 07 March 2006 18:48, Rich Felker wrote:
> >
> > > > 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.
> >
> > I think the keyword is "stumble across".
> >
> > Obviously if the muxer wants the demuxer to be able to find the packet,
> > it should put it at the start. It's acceptable IMO to not find it if it's in the
> > middle, but if it does find a new one accidentally when playing the file
> > normally, it should inform the playing application of it, and not silently
> > discard it.
>
> exactly
> * demuxer NEVER searches for info, theres no need for that
> * current muxers put same info after every main-stream header set
> * demuxer MUST pass latest found info to user app
>
> rich whats your oppinion about this?
Mostly OK. However I don't really like the third requirement since it
deals with the demuxer/app interface which so far we have left
unspecified. That is, we have specified what a compliant process
reading a NUT file must/should do, but we have not specified whether
or how this should be broken into a demuxer library and a calling
application. IMO this latter distinction does not belong in the NUT
spec. The spec should deal with the contents of the file and how it
should be interpreted, not application implementation issues.
Otherwise, OK.
Rich
More information about the NUT-devel
mailing list