diff DOCS/tech/realcodecs/streaming.txt @ 6350:a2173ca2f49c

some updates, fixes discovered by me

--- a/DOCS/tech/realcodecs/streaming.txt	Sun Jun 09 02:54:28 2002 +0000
+++ b/DOCS/tech/realcodecs/streaming.txt	Sun Jun 09 03:25:28 2002 +0000
@@ -10,14 +10,14 @@
 
 Every packet may contain one or more sub packets, and one block may
 be contained inside one or more adjacent (sub) packets.
-A sub packet starts with a small header (two letters are one byte):
+A sub packet (fragment) starts with a small header (two letters are one byte):
 
 
-aa(bb)[ccccdddd{eeee}ff]
+aa(bb)[cccc{gggg}dddd{eeee}ff]
 
 aa:   indicates the type of header
       the 2MSB indicate the header type (mask C0)
-      C0:      the [] part exists, but not ()
+      C0:      the [] part exists, but not () -> whole packet (not fragmented)
       00, 80:  the data block is encapsulated inside multiple packets.
                bb contains the sequence number, beginning with 1.
                80 indicates the last sub packet containing data for the
@@ -29,19 +29,24 @@
       40:      [] does not exist, the meaning of bb is unknown to me
                data follows to the end of the packet
       mask 3F: unknown
-bb:   unknown
-cccc: mask 3FFF: length of data
+bb:   sub-seq - mask 0x7f: the sequence number of the _fragment_
+                mask 0x80: unknown, seems to alternating between 00 and 80
+cccc: mask 3FFF: _total_ length of the packet
       mask C000: unknown, seems to be always 4000
+      when it's all 0000, it indicates value >=0x4000, you should read {gggg}
+      and use all 16 bits of it. dunno what happens when length>=65536...
 dddd: when it's 0, {} exists (only in this case)
-      mask 3FFF: I thought it would have been the offset inside the
-                 block, is not correct in every case. Just appending the
-                 data works better, ignoring it.
-      mask C000: like cccc, except the first case
-eeee: only exists when dddd exists and is zero. contains the data
-      dddd should contain in the second case. don't know what the developers
-      had in mind.
-ff:   sequence number for the data blocks, beginning with 0
+      mask 3FFF: offset of fragment inside the whole packet. it's counted
+                 from the beginning of the packet, except when hdr&0x80,
+		 hten it's relative to the _end_ of the packet, so it's
+		 equal to fragment size!
+      mask C000: like cccc, except the first case (always 4000)
+      when it's all 0000, it indicates value >=0x4000, you should read {eeee}
+      and use all 16 bits of it. dunno what happens when length>=65536...
+ff:   sequence number of the assembled (defragmented) packets, beginning with 0
 
+NOTE: the demuxer should build a table of the subpacket offsets relative to the
+start of whole packet, it's required by the rv20/rv30 video decoders.
 
 
 packet header: