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