summaryrefslogtreecommitdiffstats
path: root/DOCS/OUTDATED-tech/realcodecs/streaming.txt
diff options
context:
space:
mode:
Diffstat (limited to 'DOCS/OUTDATED-tech/realcodecs/streaming.txt')
-rw-r--r--DOCS/OUTDATED-tech/realcodecs/streaming.txt58
1 files changed, 58 insertions, 0 deletions
diff --git a/DOCS/OUTDATED-tech/realcodecs/streaming.txt b/DOCS/OUTDATED-tech/realcodecs/streaming.txt
new file mode 100644
index 0000000000..a4af485b9b
--- /dev/null
+++ b/DOCS/OUTDATED-tech/realcodecs/streaming.txt
@@ -0,0 +1,58 @@
+In the RV30 format, another encapsulated data layer for the video stream
+has been introduced. In lack of a name I'll call them sub packets, the
+normal packets which exist in RV10 I'll call - well - packets. The stream
+of bytes which is put in one memory block is named block.
+
+The format extension has been * by wild guessing and comparing the
+received data between the original viewer and the demuxer.
+
+
+
+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 (fragment) starts with a small header (two letters are one byte):
+
+
+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 () -> 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
+ current block. no C0 or 40 sub packet follows until
+ the block has been finished with a 80 sub packet.
+ No packet with another stream than the current video stream
+ is inside the sub packet chain, at least I haven't seen
+ such case - the demuxer will shout in this case.
+ 40: [] does not exist, the meaning of bb is unknown to me
+ data follows to the end of the packet
+ mask 3F: unknown
+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: 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:
+
+ushort unknown
+ulong blocksize
+ushort streamid
+uchar reserved
+uchar flags 1=reliable, 2=keyframe