[MPlayer-dev-eng] FINALIZE NUT SPEC!!

[Rich Felker]

On Mon, Feb 27, 2006 at 11:34:23AM +0100, Michael Niedermayer wrote:
> > > some specific issue iam aware of
> > > 1. metadata which becomes known after the time to which it applies cannot
> > >    be stored in info streams, i already threatened to write a info2 
> > >    extension if oded-rich info streams/packets end up with some silly
> > >    limitations ...
> > 
> > I don't object to the existence of such data, but it's not
> > stream-like. Violating the stream nature of a stream to store
> > information that does not go with the pts of the frame is not a proper
> > solution.
> 
> fine, maybe we should drop info streams then and go back to my original
> system of storing info packets as needed, that was much simpler for both
> muxer and demuxer, though it didnt conform to some arbitrary philosophical
> goals, but IIRC the current system does neither?

IMO this heavily reduces functionality. I won't object to storing
normal info packets at arbitrary locations in the file (as long as
chapter_id!=0; global packets must be file-global) but I would also
like info streams with pure stream semantics for cases (like the ones
I've described) where you need this behavior to represent realtime
data.

> > 2. PCM audio must be framed such that no frame entirely overlaps more
> >    than 1 whole frame from any other stream.
> 
> umm, thats even more stupid, think about remuxing, you add some stream with
> small frames, now you must re-frame all PCM streams .

Agree, it's stupid. I was just giving you a summary of the discussion
of options I didn't like.

> > IMO PCM is already such a format that needs additional specification,
> > since we need to specify the extradata format (or else many fourcc's)
> > for all the different sample formats.
> 
> and ADPCM, mu-law, a-law, ... codecs? they all have very small packets
> 
> my suggestion:
> add a packet_size field to the stream header, which is 0 if the size is
> variable and add a rule like:
> 1 codec packet MUST be only in one NUT packer (=no splited packets)
> 1 NUT packet MUST contain exactly 1 codec packet if the NUT packet is larger
> then 4kb or packet_size is 0

Hm.. I'm not entirely against this, but I don't like the 4kb limit.
It's way too high. Someone could store a huge amount of CBR mp3 data
in one NUT packet as long as they used low bitrate and a samplerate
that makes all packets identical size.

Rather than an arbitrary size, is there perhaps a better way we could
do this?

Also I don't like supporting this for arbitrary codecs. The reason is
that you have to do one of two things in the demuxer, and both are
wrong for certain cases. You must either:

1. Output the whole NUT packet as one unit. This is wrong for codecs
   that actually use frames.

2. Split the NUT packet into frames according to packet_size and
   output each individually. This is horribly wrong for PCM as it will
   make CPU usage insanely high.

IMO special-casing PCM/ADPCM as codecs where any block of data up to X
samples long is a valid 'frame' is a cleaner solution, but I'm open to
alternatives for sure.

Rich