[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