Info packets in NUT stream (spec bugs?)

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel