initial version from Florian Schneider <flo-mplayer-dev@gmx.net>

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

4 files changed, 308 insertions, 0 deletions

diff --git a/DOCS/tech/realcodecs/TODO b/DOCS/tech/realcodecs/TODO
new file mode 100644
index 0000000000..bf88f89d63
--- /dev/null
+++ b/DOCS/tech/realcodecs/TODO
@@ -0,0 +1,18 @@
+TODO:
+
+- more docs are coming as I find the time to write them down
+- USE_REALCODECS is needed in config.h -> configure
+- 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
+- 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
+- audio support (mainly for COOK)
+- RV20 support
+- internet streaming support
+- searching
+- get it to work before (they stream) the Bizarre festival
+
diff --git a/DOCS/tech/realcodecs/audio-codecs.txt b/DOCS/tech/realcodecs/audio-codecs.txt
new file mode 100644
index 0000000000..61259deb2b
--- /dev/null
+++ b/DOCS/tech/realcodecs/audio-codecs.txt
@@ -0,0 +1,58 @@
+all audio codecs (cook,atrk,14_4,28_8,dnet,sipr) have the same interface,
+but i have only analyzed the cook codec
+
+
+audio properties
+
+00 short text/description of the format (bitrate, when to use)
+01 avg. bytes/sec output
+02 ulong: ?
+   ulong: samples per second
+   ushort: bits/sample
+   ushort: number of channels
+03 constant 2
+04 long description
+05 constant 1 (always?)
+06 ulong: block align (input frame for RADecode)
+07 string: minimum player version
+08 n/a
+09 n/a
+0A n/a
+0B n/a
+0C n/a
+0D ?
+0E ?
+0F ?
+10 ?
+11 ?
+12 ?
+13 min. output buffer size? max. number of samples?
+14 ?
+
+
+
+
+functions:
+
+ulong result=RAOpenCodec2(ra_main_t *raMain);
+
+ulong result=RAInitDecoder(ra_main_t *raMain, p2);
+p2=?
+
+
+void *GetRAFlavorProperty(ra_main_t *raMain, ulong flavor, ulong property,
+	short *property_length_in_bytes);
+returns property data for a specific data
+
+ulong RADecode(ra_main_t *raMain, char *input_buffer,
+	ulong input_buffer_size, char *output_buffer,
+	ulong *decoded_bytes, ulong p6=-1);
+
+RAFreeDecoder(ra_main_t *);
+
+RACloseCodec(ra_main_t *);
+
+
+ulong RASetFlavor(ra_main_t *ra_main, ulong flavor);
+a flavor is an entry in the list of available format variations like
+bitrate, number of channels, decoding algorithm, and so on
diff --git a/DOCS/tech/realcodecs/streaming.txt b/DOCS/tech/realcodecs/streaming.txt
new file mode 100644
index 0000000000..483f91a19d
--- /dev/null
+++ b/DOCS/tech/realcodecs/streaming.txt
@@ -0,0 +1,55 @@
+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 starts with a small header (two letters are one byte):
+
+
+aa(bb)[ccccdddd{eeee}ff]
+
+aa:   indicates the type of header
+      the 2MSB indicate the header type (mask C0)
+      C0:      the [] part exists, but not ()
+      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:   unknown
+cccc: mask 3FFF: length of data
+      mask C000: unknown, seems to be always 4000
+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
+
+
+
+packet header:
+
+ushort unknown
+ulong  blocksize
+ushort streamid
+uchar  reserved
+uchar  flags 1=reliable, 2=keyframe
+
+
diff --git a/DOCS/tech/realcodecs/video-codecs.txt b/DOCS/tech/realcodecs/video-codecs.txt
new file mode 100644
index 0000000000..e2cff7e338
--- /dev/null
+++ b/DOCS/tech/realcodecs/video-codecs.txt
@@ -0,0 +1,177 @@
+The work has been based on the RV30 codec, but since RV20 has the same
+interface, it might work for it as well.
+
+
+
+
+error codes (the software uses redmond originated error codes)
+
+1. internal code (1-10)
+2. result
+
+0    00000000 success
+1    80004005 E_FAIL
+2    8007000E E_OUTOFMEMORY
+3,9  80004001 E_NOTIMPL
+4,5  80070005 E_ACCESSDENIED
+6    80004003 E_POINTER
+7,10 80070057 E_INVALIDREG
+8    80040FC1 (or 1FC?: CO_E_OBJISREG) - never occured here
+
+
+
+
+
+I think the only relevant file is the decoder drv[23].so.6.0
+The rv[23]0 ones are just for streaming. We do this ourselves.
+
+
+The codec consists of several functions. The relevant ones are:
+
+RV20toYUV420Init()
+RV20toYUV420Transform()
+RV20toYUV420CustomMessage()
+RV20toYUV420Free()
+
+
+The others are irrelevant (seems to me). HiveMessage doesn't manipulate
+anything and is only called in the beginning.
+
+result=RV20toYUV420Init(struct init_data *, struct rvyuvMain **);
+
+struct init_data {
+	short constant=0xb;
+	short width, height;
+	short 0, 0, 0;
+	ulong format1;
+	long  1;
+	ulong format2;
+};
+
+
+result=RV20toYUV420Transform(char *input_stream, char *output_data,
+	struct transin *, struct transout *, struct rvyuvMain *);
+
+struct transin {
+	ulong length_of_input_data;
+	ulong null;
+	ulong num_sub_packets_in_block_minus_one;
+	struct transin1 *ptr;
+	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
+	ulong zero;
+	ulong width, height;
+};
+
+The length of output_stream is 1.5*width*height.
+input_stream is the exact data from the data block for one frame.
+
+
+
+result=RV20toYUV420CustomMessage(ulong *msg, struct rvyuvMain *);
+
+Messages used by RV30:
+
+A message is a triplet (cmd,val,ext) of ulong.
+
+(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
+
+(0x11,0|1|2,0)
+val=0|1: sets intern2 to val, when intern1 is non-zero
+         return 3 when intern1 is zero and val is 1
+         else returns 0
+val=2:   return intern2
+what does intern[1,2] mean?
+
+(0x1e,2|3,1)
+calls a subroutine and returns the result, purpose has to be detemined
+
+(0x24,2,{...})
+copies 4 dwords to rvyuvMain+07c: { width, height, 0, 0 }
+
+(0x1c,a,b) - called inside transform
+to be analyzed
+
+
+
+structure of rvyuvMain:
+-----------------------
+
+DWORDS (the entries are not always constant)
+there are two w/h pairs at 05C. the first is the size of the
+unscaled video stream, the second possibly image size
+
+000	1	6	3	1
+010	1	0	AEBFC0D1(magic)	0
+020	0	ptr->?	0	0
+030	0	0	->rvyuvMain+0x050	?
+040	width	height	0x17	0x479
+050	->rvyuvMain	0x17	0x17	width
+060	height	width	height	0
+070	0	1	0	0
+080	0	0xb	w	h
+090	w	h	0	0	
+0A0	1	0xb0(w?)	0x58	0x58
+0B0	ptr->?	0	0	1
+0C0	0x32	1	0	0
+0D0	0	0	0	0
+0E0	0	0	0	0
+0F0	0	0	0	0
+100	0	0	0	0
+110	p	p	p	p p are pointers to several function, for 
+120	p	p	p	p example to the actual public functions
+130	p	p	p	p (except init, the others are some kind of
+140	p	p	p	p interfaces)
+150	p	0	0	0
+160	0	0x2000	1	0
+170	0	0	0	0
+180	1	1	0	0
+190	0	0	0	0
+1A0	0	0	0	0
+1B0	1	0	ptr->?	ptr->?
+1C0	1	0	0	0
+1D0	0	0	0	0
+1E0	0	0	0	0
+...
+
+
+
+
+Order of calls:
+---------------
+
+Init
+(0x11,0,0)
+(0x24,2,{...})
+
+[
+(3,2,0)->80004001
+(0x11,1,0)
+(0x1e,3,1)
+Transform (internally calls (0x1c,x,y))
+(11,2,0)
+]
+
+Free
+
+