[MPlayer-dev-eng] NUT cleanup

Michael Niedermayer michaelni at gmx.at
Sat Sep 3 17:40:57 CEST 2005


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


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


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


> 
> 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 :)


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


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

[...]

-- 
Michael




More information about the MPlayer-dev-eng mailing list