[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

Hi

On Sat, Nov 04, 2006 at 03:53:13PM +0200, Oded Shimon wrote:
> hmm, several bugs found in spec?
> 
> from spec:
> > If a info packet is stored anywhere then a muxer MUST also store an identical
> > info packet after every main-stream-header set
> 
> This is nonsense in real time streaming, isn't it?.. In real time 
> streaming, the only rule i suggest there should be is that after a 
> main-header set, there should be all global info packets (chapter_id==0), 
> and info packets applying to the current chapter. (e.g., if you joined in 
> the middle of a song, you should get the info packet telling about the 
> song)

the problem is not specific to realtime streaming but streaming in general
think of a 1 week long file made of 1min long songs, streaming that in a
non seekable way makes it impossible to place all info packets after every
main-stream header set, the problem is that non seekability and streaming
will need headers and info to be repeated often ...

i have several suggestions to reduce this problem
1. require info packets (after the mainheader) to be ordered by their
   start time
2. drop the requirement you quoted above for
   streams for which no bidirectional out of band channel exists and 
   which are neither seekable
3. dissallow main/streamheaders and info packets in the normal stream
   if an out of band system to transmit them is available

1 has the advantage of O(log n) vs. O(n) time for files with really
many info packets (no effect on demuxer complexity unless it wants to
use this additional ordering for quickly finding stuff, and IMHO small
effect on muxer complexity, new files would always be valid in the
old spec) maybe this could be added as a SHOULD requirement? maybe
with a info packet saying sorted=1 or so?

2 should fix your complaint? the muxer would then have to place info
based on the following 2 rules in the current spec:
----
If a demuxer has seen several info packets with the same chapter_id and
stream_id then it MUST ignore all but the one with the highest position in
the file

demxuxers SHOULD NOT search the whole file for info packets
----

3 ensures that no half valid nut files are laying around in case info
packets are updated out of band (a client would either dump the stream
blindly which would result in an unplayable stream, or dump it and then
add the latest info and mainheaders)

comments welcome ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is