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

[Michael Niedermayer]

Hi

On Mon, Feb 27, 2006 at 01:25:28PM -0500, Rich Felker wrote:
> 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.

yes, but that realtime data could very well become available afterwards
lets say some realtime news of a earthquake, its magnitude, number of
casualties and so on wont be known immedeatly
furthermore estimates will change, and if you dont like that example, take
any other realtime stream (some DJ with music videos whatever) where info
is added in realtime some mistakes will creep in and it should be possible
to correct them, in such a way that automatic remuxing updates all info
thats not hard but with our strict rules its impossible. so with these
restrictions i see no sense in info streams


[...]
> > > 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.

what about allowing it only for <4kbyte && <4ksamples ?


[...]
-- 
Michael