some updates, fixes discovered by me

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@6351 b3059339-0415-0410-9bf9-f77b7e298cf2

3 files changed, 51 insertions, 36 deletions

diff --git a/DOCS/tech/realcodecs/TODO b/DOCS/tech/realcodecs/TODO
index bf88f89d63..37450eadf1 100644
--- a/DOCS/tech/realcodecs/TODO
+++ b/DOCS/tech/realcodecs/TODO
@@ -1,18 +1,18 @@
 TODO:
 
 - more docs are coming as I find the time to write them down
-- USE_REALCODECS is needed in config.h -> configure
+- USE_REALCODECS is needed in config.h -> configure - DONE
 - the original player is doing something I don't know of:
   I compare the input and output data of the original and mplayer.
-  While the input is the same, the ouput differs.
-- the frame rate is incorrect
+  While the input is the same, the ouput differs. - DONE
+- the frame rate is incorrect - WHY?? need sample, can't reproduce
 - use RV20toYUV420Free()
 - rvyuvMain and the two format dwords should be stored inside
   st_context, so we don't use constants in the demuxer and the
-  wrapper
+  wrapper - DONE
 - audio support (mainly for COOK)
-- RV20 support
+- RV20 support - DONE
 - internet streaming support
 - searching
-- get it to work before (they stream) the Bizarre festival
+- get it to work before (they stream) the Bizarre festival :)
 
diff --git a/DOCS/tech/realcodecs/streaming.txt b/DOCS/tech/realcodecs/streaming.txt
index 483f91a19d..3761c04b5a 100644
--- a/DOCS/tech/realcodecs/streaming.txt
+++ b/DOCS/tech/realcodecs/streaming.txt
@@ -10,14 +10,14 @@ 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 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 @@ aa:   indicates the type of header
       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:
diff --git a/DOCS/tech/realcodecs/video-codecs.txt b/DOCS/tech/realcodecs/video-codecs.txt
index e2cff7e338..926b8f8bed 100644
--- a/DOCS/tech/realcodecs/video-codecs.txt
+++ b/DOCS/tech/realcodecs/video-codecs.txt
@@ -48,6 +48,9 @@ struct init_data {
 	ulong format2;
 };
 
+format1 and format2 are stored in the .rm file's stream headers.
+(format1>>16)&3 seems to be a sub-codec id/selector, at least for rv30
+it's the only difference between low and high bitrate files.
 
 result=RV20toYUV420Transform(char *input_stream, char *output_data,
 	struct transin *, struct transout *, struct rvyuvMain *);
@@ -56,24 +59,11 @@ struct transin {
 	ulong length_of_input_data;
 	ulong null;
 	ulong num_sub_packets_in_block_minus_one;
-	struct transin1 *ptr;
+	ulong *sub_packets_list;
 	ulong another_null;
 	ulong timestamp_from_stream;
 };
 
-struct transin1 {
-	ulong 1, 0;
-	// ... more data? the codec's behaviour changed sometimes
-	// when I changed the data following the first to ulongs
-	// i.e. it crashed. I've set it to 0
-	// TODO: understand (the purpose of) these values
-	// often contains 0x28, 0x19
-	// sometimes 0x28, 0x11
-	// sometimes even other data (e.g. pointers)
-	// a breakpoint didn't reveal a read operation. weird.
-};
-
-
 struct transout {
 	ulong flag1; // ((var_94&2!=0)&&(result==0))?1:0
 	ulong flag2; // 4 LBS from var_94
@@ -81,9 +71,17 @@ struct transout {
 	ulong width, height;
 };
 
-The length of output_stream is 1.5*width*height.
+The length of output_stream is 1.5*width*height (I420 planar yuv 4:2:0).
 input_stream is the exact data from the data block for one frame.
 
+sub_packets_list is a list of num_sub_packets pairs of long values, in form:
+1, 0,
+1, offset_2nd,
+1, offset_3rd,
+1, offset_4th,
+...
+
+where offset_* are the offsets or sub-packets relative to input_stream.
 
 
 result=RV20toYUV420CustomMessage(ulong *msg, struct rvyuvMain *);
@@ -92,6 +90,10 @@ Messages used by RV30:
 
 A message is a triplet (cmd,val,ext) of ulong.
 
+NOTE:
+rv30 only requires the (0x24,2|3,{w,h,w,h}) message. others can be left out!
+rv20 only requires the (0x11,2,0) message in rp8, before each transform call.
+
 (3,2,0) 
 returns always(?) an error, since a global variable inside the codec
 (which points to a function similar to custommessage), is always NULL
@@ -103,15 +105,23 @@ val=0|1: sets intern2 to val, when intern1 is non-zero
 val=2:   return intern2
 what does intern[1,2] mean?
 
+(0x12,...)
+used by rv20, function unknown, can be ignored
+
 (0x1e,2|3,1)
 calls a subroutine and returns the result, purpose has to be detemined
 
-(0x24,2,{...})
+(0x24,subcodec,{...})
 copies 4 dwords to rvyuvMain+07c: { width, height, 0, 0 }
+subcodec must be 2 (low-bitrate) or 3 (high-bitrate) for rv30.
+the codec type (low vs high) can be determined from 1+((format1>>16)&3)
+for rv20, this call should be ignored! (makes codec crashing)
 
 (0x1c,a,b) - called inside transform
 to be analyzed
 
+(105,...)
+used by rv20, function unknown, can be ignored
 
 
 structure of rvyuvMain: