Hi On Mon, Mar 06, 2006 at 10:39:01AM +0200, Ivan Kalvachev wrote: [...]
this is not a cosmetic issue, you guys want restrictions which make no sense and which restrict actually usefull and needed cases
heres what i have in my nut fork on my disk: (note, there are no info streams)
Rules for realtime streams:
If a info packet X is transmitted anywhere then an info packet with the same chapter and stream_id MUST be placed so that there is never a mainheader and following frame covered by the info packet without the info packet inbetween example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info) M f f M f I f F F M I F F M I F F f f M f f M as a special exception very large and unimportant info packets can be transmitted less often
If 2 info packets have the same chapter_id and stream_id then the earlier MUST be ignored (the last info packet is the most correct, this allows updating or correcting info)
Rules for non realtime streams:
2 info packets with the same chapter_id and stream_id MUST be identical
Every info packet which is stored anywhere in the file MUST also be stored after every mainheader-streamheader set
Somehow I don't like to distinguish between realtime and non-realtime streams.
I am concern about how will the later info stream be found on seeking. It is quite possible for it to be missed. (assuming you can seek in realtime stream, e.g. by storing or buffering it).
well, lets see, if the seek happens purely in the clients buffer then theres no issue as the client must have seen all the needed info already, that leaves the issue with asking the server to seek to X, here there are a few specific cases 1. the server dynamically inserts the needed info (no problem) 2. back_ptrs are set so that they point to the info pakets (no problem) 3. back ptrs ignore info packets (problem here) so only case 3 matters for us, we could simply add a rule that dissalows it in realtime streams now how does the rich-oded proposal differ, not at all their info streams would either force back_ptrs to point to info frames or would missuse EOR and cause info not to be found, we can achive the same here so again lets see which solutions there would be for case 3 (serverside seek but server is not able to dynamically insert info packets and backptrs ignore info packets) A. dissalow it B. use info streams and dissalow ranodom EORs (practically identical to A.) C. per stream back ptrs and pts in the syncpoints, and require the demuxer to seek first to the info packets and then seek to the actual video/audio (O(N*log(N)) overhead per N streams, mandatory high complexity on the demuxer side) iam in favor of A. and iam strongly against C. [...] -- Michael