[NUT-devel] Freeze NUT spec?

[Rich Felker]

On Tue, Mar 28, 2006 at 08:23:24PM +0200, Oded Shimon wrote:
> On Tue, Mar 28, 2006 at 01:14:14PM -0500, Rich Felker wrote:
> > On Tue, Mar 28, 2006 at 07:09:02PM +0200, Oded Shimon wrote:
> > > I think you misunderstand..
> > > 
> > > step 1: mplayer probe - read N bytes, check if it matches startcode/id.
> > > step 2: call libnut and start demuxing
> > > 
> > > The problem is, mplayer's probe sucks, and it _discards_ the N bytes you 
> > > just read. you will either have to seek back to begginning of stream 
> > 
> > No, mplayer's stream layer handles this. Otherwise all probing for all
> > formats would be broken.
> 
>   CPLAYER: Playing -.
>      OPEN: Reading from stdin...
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
> Win32 LoadLibrary failed to load: avisynth.dll, /usr/local/lib/codecs/avisynth.dll, /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>    STREAM: Cannot seek backward in linear streams!
>    STREAM: Seek failed
>   DEMUXER: MPEG-PS file format detected.
>   <plays fine...>
> 
> I'm actually not sure about all this, but IMO MPlayer stream layer just 
> sucks beyond belief regardless, it can't even update end of file position 
> for growing files (but it can read past it). (You can't find out the new 
> filesize)

IMO it's a bug in some of the demuxers which causes them to read past
the max stream buffer length when probing.

> > > Starting after a probe of 'file_id' is fine, because libnut doesn't need 
> > > it, but if you "eat up" the main startcode from begginning of file, 
> > > libnut will choke looking for it.
> > 
> > If libnut doesn't need it then libnut is not compliant to the spec. :)
> 
> Ahem, error handling. It does check for file_id string, but if not found, 
> it just starts linear searching for startcode.

OK, never mind. :)

> > 1. Use the same mess as AVI & friends with 10-20 fourcc's for each
> >    codec.
> > 2. Require a single fourcc per codec, using an existing common name
> >    for the standard (like MP4S or H264) if available and never using
> >    vendor-specific names.
> 
> I'm generally OK with this...

Yeah me too. Just wondering if we could/should do better.

> > 3. Require a single fourcc (or more generally, codec id) per codec,
> >    using our own nomenclature. One past proposal I made was to use the
> >    official name of the document that specifies the compression
> >    format, and in the case of reverse-engineered proprietary formats
> >    this would be the name of the DLL file. :) Of course I'm open to
> >    other options too.
> 
> So, divx fourcc would be "ISO/IEC 14496-2" ?... I was actually considering 

Yes.

> maybe just using ffmpeg's CODEC_ID stuff :)

You mean the numbers? Or the strings CODEC_ID_*? Using the numbers is
a bad idea IMO since they're just arbitrary implementation-internal
constants.

> > IMO 3 is the cleanest and most format, while 2 is probably more
> > pradmatic. In some senses 1 is probably the most pragmatic but also
> > disgusting, and it certainly isn't appropriate for audio..
> 
> I wasn't actually refferring to hardware plays at all, I was actually 
> thinking of mplayer. mplayer currently works "out of the box" with nut. 
> Adding _more_ mappings to the mess would be... silly. But I don't really 
> care about all this. Whatever works, I'm fine with it...

If we designed NUT around mplayer's brokenness, NUT would be complete
shit... :) In fact it would be AVI. :))))))))

Rich