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