[NUT-devel] Re: FINALIZE NUT SPEC!!

[Rich Felker]

Moving to nut-devel list...

On Mon, Feb 27, 2006 at 08:08:55PM +0100, Michael Niedermayer wrote:
> 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

OK, how about this: drop the requirement that they be
binary-identical, and instead the last packet with the given
chapter_id is the one that's valid. Keep the rest of the semantics for
what range it applies to. This allows updating/correcting info in a
live stream and will give the correct results if you convert it to an
info packet for permenant storage (using the latest/most correct
data). Also this allows you to specify length if it becomes known.

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

It still doesn't solve the problem about how do demux. How about this
instead:

- Storing multiple frames together is allowed only if the concatenation
  of all frames is also a valid single frame for the format.

This way the demuxer can always output the whole frame as a unit and
doesn't have to decide whether that's safe or not. But, having the
packet_size (should be called frame_size...?) in the header is still
useful, since it would allow more fine-grained seeking in a
special-purpose application like a media editor.

We can also put a limit on number of samples. IMO there's no real need
for a size limit, and if there is a size limit it should probably be
relative to max_distance rather than absolute. If we really want to
avoid absolutes, we could make the sample limit relative to
max_pts_diff too...

Rich