[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Sat, Sep 03, 2005 at 05:40:57PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Sep 03, 2005 at 06:07:57AM -0400, Rich Felker wrote:
> > Some things Oded(ods15) and I have found while reading the NUT spec
> > and working on a possible independent implementation:
> > 
> > 1. In stream_header, stream_id field is redundant since the headers
> >    are required to be stored in order. Removing this field would
> >    enforce the requirement that they be stored in order, but also
> >    might make it more difficult to recover some streams from a damaged
> >    file in the absence of backup headers..?
> 
> IMHO stream_id should be left there

OK.

> > 2. Time base num/den have opposite meaning in NUT from what they mean
> >    in libavformat. That is to say, lavf's idea of the time base would
> >    be 1001/30000 whereas NUT's would be 30000/1001. I'd like to rename
> >    the fields in the NUT spec to be consistent with lavf usage, which
> >    seems more logical.
> 
> ok, but they sould not be reordered so as to avoid compatibility breakage

Of course. I won't reorder them, just rename them to make sense.

> > 3. In the audio stream header, we have a channel count.. is this
> >    useful? IMO knowing a channel count without a channel arrangement
> >    is useless except for mono/stereo. For PCM formats, we'll need a
> >    separate fourcc (or extradata) for each channel layout anyway, and
> >    for compressed audio the output channel order (and possibly even
> >    the number of channels output) is dependent on the decoder
> >    implementation.
> 
> hmm, my first thought about this is yes, its usefull because when you
> streamcopy from nut to some other container then the number of channels 
> will often be needed

Hmm, undecided then?

> > 4. Index. There's no pointer at the end of the file pointing back to
> >    the beginning of the index, so you have to keep seeking back and
> >    searching (without bound) for the index startcode. I'd propose
> >    either an end-of-index startcode followed by a vlc-coded
> >    backpointer to the index, or a reverse-vlc-coded backpointer at the
> >    end of the index.
> 
> hmm, somehow i think simply writing a 64bit int at the end
> would be the simplest, its even shorter then a startcode + vlc :)

Yes but it's rather bleh.. I hate fixed-size fields, even tho index
size would never be bigger than 24 bits anyway. What about a vlc
written in reverse byte order?

> > 5. FIXME? Line 316: stream_id[FIXME].. no idea what the FIXME is for.
> 
> ask Luca Barbato, it was in a patch from him according to cvs annotate

OK.. :)

> MN1. should i always edit mpcf.txt after we agree on something or should
> the one who proposed a change edit mpcf.txt?

I don't really care which way we do it. But.. I would like to remove
mncf.txt since its presence seems to be confusing people.

Rich