[NUT-devel] Freeze NUT spec?

[Oded Shimon]

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)

> > 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.

> > > > > > > - We need a spec for what goes in the fourcc field, especially for
> > > > > > >   audio, but it may also be an issue for video. Are XVID, DIVX, DX50,
> > > > > > >   etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
> > > > > > 
> > > > > > seperate from freeze/finalizing...
> > > > > 
> > > > > No it's not.
> > > > 
> > > > OK... Start writing then.
> > > 
> > > >_<
> > > Do you have thoughts on which way we should go with it?
> > 
> > Uhh.... No idea.
> > More or less same as current formats, not be a pain in the ass. As in, I 
> > wouldn't mind using MP4S if players actually support it. If not, I say 
> > just use XVID... (Though it would be weird for a spec strictly saying to 
> > use something like "XVID")
> 
> Using XVID for everything is absolutely wrong. There's no need to
> maintain compatibility with the expectations of stupid hardware
> players since they don't even support NUT yet. IMO the options are:
> 
> 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...

> 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 
maybe just using ffmpeg's CODEC_ID stuff :)

> 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...

- ods15