[NUT-devel] [nut]: r613 - docs/nutissues.txt

[Alban Bedel]

On Tue, 12 Feb 2008 17:57:03 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Tue, Feb 12, 2008 at 05:47:13PM +0100, Alban Bedel wrote:
> > On Tue, 12 Feb 2008 16:00:10 +0100 (CET)
> > michael <subversion at mplayerhq.hu> wrote:
> > 
> > > Modified: docs/nutissues.txt
> > > ==============================================================================
> > > --- docs/nutissues.txt	(original)
> > > +++ docs/nutissues.txt	Tue Feb 12 16:00:09 2008
> > > @@ -162,3 +162,8 @@ How do we identify the interleaving
> > >  A. fourcc
> > >  B. extradata
> > 
> > I would vote for this with a single fourcc for pcm and a single
> > fourcc for raw video. Having infos about the data format packed in
> > the fourcc is ugly and useless. That just lead to inflexible lookup
> > tables and the like. 
> 
> > Instead we should just define the format in a way similar to what
> > mp_image provide for video (colorspace, packed or not, shift used
> > for the subsampled planes, etc). That would allow implementations
> > simply supporting all definable format, instead of a selection of
> > what happened to be commonly used formats at the time the
> > implementation was written.
> 
> The key points here are that
> * colorspace/shift for subsampled planes, etc is not specific to RAW,
> its more like sample_rate or width/height

Sure, but when a "real" codec is used, it's the decoder business to tell
the app what output format it will use. NUT can provide infos about the
internal format used by the codec, that would help dealing with decoder
including slow colorspace conversions. But that's definitly
non-essential information, any player should be able to do without it.

However for RAW data the "decoder" need to know the exact format used,
just like some other decoder need some huffman tables or whatever.
And the logical place for such information is the extradata imho.

> * non raw codecs have clearly defined global headers (sometimes at
> least) -> thus we cant really use extradata for it
>    extradata would only be ok for things we definitly dont ever need
> for non raw

imho the 2 case are completly different. For raw codecs we are talking
about informations essential to the decoder initialization. For non raw
codecs we are talking about some extra informations only usefull in some
applications. Both need to encode the same type of informations but imho
they should be stored in different places.

> > 
> > >  C. New field in the stream header
> > > +D. Only allow 1 standard interleaving
> > > +
> > > +What about the interleaving of non raw codecs, do all specify the
> > > +interleaving, or does any leave it to the container? If so, our
> > > options +would be down to only C.
> > 
> > On a related subject, it might also be useful to define the channel
> > disposition when there is more than one. Mono and stereo can go by
> > with the classical default, but as soon as there is more channels
> > it is really unclear. And imho such info could still be usefull
> > with 1 or 2 channels. Something like the position of each channel
> > in polar coordinate (2D or 3D?) should be enouth.
> 
> I agree
> What about that LFE channel thing?

I was thinking about simply setting the distance to 0, however a flag
for "non-directional" channels might be better.

> And where do we put this info, The stream header seems the logic
> place if you ask me ...

I agree, this is essential information for proper presentation it
definitly belong there.

	Albeu