[Mplayer-cvslog] CVS: main/DOCS/tech/realcodecs TODO,1.1,1.2 streaming.txt,1.1,1.2 video-codecs.txt,1.1,1.2

[Arpi of Ize]

Update of /cvsroot/mplayer/main/DOCS/tech/realcodecs
In directory mail:/var/tmp.root/cvs-serv22177

Modified Files:
	TODO streaming.txt video-codecs.txt 
Log Message:
some updates, fixes discovered by me


Index: TODO
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/realcodecs/TODO,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TODO	9 Jun 2002 02:54:28 -0000	1.1
+++ TODO	9 Jun 2002 03:25:28 -0000	1.2
@@ -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 :)
 

Index: streaming.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/realcodecs/streaming.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- streaming.txt	9 Jun 2002 02:54:28 -0000	1.1
+++ streaming.txt	9 Jun 2002 03:25:28 -0000	1.2
@@ -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:

Index: video-codecs.txt
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/tech/realcodecs/video-codecs.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- video-codecs.txt	9 Jun 2002 02:54:28 -0000	1.1
+++ video-codecs.txt	9 Jun 2002 03:25:28 -0000	1.2
@@ -48,6 +48,9 @@
 	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 @@
 	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 @@
 	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 @@
 
 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=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: