diff options
Diffstat (limited to 'DOCS/OUTDATED-tech/realcodecs')
| -rw-r--r-- | DOCS/OUTDATED-tech/realcodecs/TODO | 22 | ||||
| -rw-r--r-- | DOCS/OUTDATED-tech/realcodecs/audio-codecs.txt | 155 | ||||
| -rw-r--r-- | DOCS/OUTDATED-tech/realcodecs/streaming.txt | 58 | ||||
| -rw-r--r-- | DOCS/OUTDATED-tech/realcodecs/video-codecs.txt | 185 |
4 files changed, 0 insertions, 420 deletions
diff --git a/DOCS/OUTDATED-tech/realcodecs/TODO b/DOCS/OUTDATED-tech/realcodecs/TODO deleted file mode 100644 index 5ba035bfdd..0000000000 --- a/DOCS/OUTDATED-tech/realcodecs/TODO +++ /dev/null @@ -1,22 +0,0 @@ -TODO: - -- more docs are coming as I find the time to write them down -- use RV20toYUV420Free() -- audio support - nearly DONE (look below) -- internet streaming support -- searching - we need to take care of the audio interleaving - - haven't taken steps to locate audio key frames (does such thing - exist?) -- some media files can't be played (mplayer crashes/fails) because - it asks for decoded audio data, but the buffer in the audio - demuxer packets are empty/missing. It seems that the necessary - audio packets haven't been decoded completely (incomplete interleaving) - the audio stream packets may get mixed with video stream packet - DONE ??? -- put variables for audio streaming inside real_priv_t -- audio support for other formats than COOK - use a switch - (like -forcereal) to activate it - no switch needed, win32 codecs - doens't work (it was a nonworking attempt) -- postprocessing support (see rp8 preferences->performance->cpu usage, - also statistics->streams->video->POST FILTER: ON - (i've found that custommessage calls differ wiht pp on/off, but adding - these calls to mplayer didn't make a pixel difference between outputs) diff --git a/DOCS/OUTDATED-tech/realcodecs/audio-codecs.txt b/DOCS/OUTDATED-tech/realcodecs/audio-codecs.txt deleted file mode 100644 index fd28ab2a16..0000000000 --- a/DOCS/OUTDATED-tech/realcodecs/audio-codecs.txt +++ /dev/null @@ -1,155 +0,0 @@ -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 (hex) - -00 short text/description of the format (bitrate, when to use) -01 bitrate (bits/s) //avg. bytes/sec output -02 ulong: ? - ulong: samples per second - ushort: bits/sample - ushort: number of channels -03 same as 02 //constant 2 -04 long description -05 constant 1 (always?) -06 ulong: block align (input frame size for RADecode) -07 string: minimum player version -08 n/a -09 n/a -0A n/a -0B n/a -0C n/a -0D ? -0E ? leaf size -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, ra_init_struct *raInit); -struct ra_init_struct { - ulong sample_rate; - ushort bits_per_sample; // unused by RAInitDecoder - ushort number_of_channels; - ushort unknown1; // 0 - ushort unknown2; // also unused (100) - ulong leaf_size; // leaf size (used for interleaving, but - // exists in audio stream description header (ASDH)) - ulong block_align; // packet size - ulong bits_per_sample; // unused (always 16) - char *ext_data; // 16 bytes located at the end of the - // ASDH -}; - -There are some information missing that you usually need for playback, -like bits per sample (the fileds aren't read by RAInitDecoder()). These -are hard coded in the "flavors", i.e. the sub formats. A flavor is an entry -in the list of available format variations like bitrate, number of channels, -decoding algorithm, and so on.We can get those information with the -following command: - - - -void *GetRAFlavorProperty(ra_main_t *raMain, ulong flavor, ulong property, - short *property_length_in_bytes); -returns property data for a specific data - -This is not important, because it's just a read only function. -These flavor properties don't seem to exist in - - -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); - -Set the flavor of the stream. - -a flavor is an entry in the list of available format variations like -bitrate, number of channels, decoding algorithm, and so on - - -audio data storage: -------------------- - -With Real Audio V5 (or earlier?), the audio streams can be interleaved, -i.e. the stream is striped amongst several data packets. The packets -(which have a fixed size packet_len) are split up into a fixed number -of num_parts equally sized parts - I call them leaves in lack of -better name. The leaves have the size leaf_size = packet_len / num_parts. - -To create a bunch of packets, you need 2*num_parts stream packets. -The first part of the first stream packet is stored in leaf number 0, -the first part of the second into leaf number num_parts, the one of the -next one into leaf number 1 etc. The following part of a stream packet -is stored 2*num_packets behind the current part of the same stream packet. - -In short words: when you have a matrix with the leaves as the values, -it's a transposition in conjunction with a permutation. - -packet | leaf | stream packet, part no. --------+---------------+------------------------ -0 | 0 | (0,0) -0 | 1 | (2,0) -. | . | . -. | . | . -0 | num_parts-1 | (2*num_parts-2,0) -0 | num_parts | (1,0) -0 | num_parts+1 | (3,0) -. | . | . -. | . | . -0 | 2*num_parts-1 | (2*num_parts-1,0) -1 | 0 | (0,1) -. | . | . -. | . | . - - -sequence of calls: ------------------- - -RAOpenCodec2() - -RAInitDecoder() - -RASetFlavor() - -RAGetFlavorProperty(0xE) - -sequence of RADecode()s - -once a RAGetFlavorProperty(0xE) after some RADecode()s - -and occasionally the following sequence: -RAGetFlavorProperty(0) -RAGetFlavorProperty(7) -which is rather pointless because they only return -cleartext audio descriptions - -RAFreeDecoder() - -RACloseCodec() - - - -RAFlush(ra_main_t *raMain, char *output_buffer, ulong *retval) -will be called when seeking -output_buffer points to the output buffer from the last -decode operation. -retval is unknown, returning always 0x18 in a specific sample --> further investigation needed diff --git a/DOCS/OUTDATED-tech/realcodecs/streaming.txt b/DOCS/OUTDATED-tech/realcodecs/streaming.txt deleted file mode 100644 index a4af485b9b..0000000000 --- a/DOCS/OUTDATED-tech/realcodecs/streaming.txt +++ /dev/null @@ -1,58 +0,0 @@ -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 diff --git a/DOCS/OUTDATED-tech/realcodecs/video-codecs.txt b/DOCS/OUTDATED-tech/realcodecs/video-codecs.txt deleted file mode 100644 index af2152061a..0000000000 --- a/DOCS/OUTDATED-tech/realcodecs/video-codecs.txt +++ /dev/null @@ -1,185 +0,0 @@ -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 occurred 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; -}; - -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 *); - -struct transin { - ulong length_of_input_data; - ulong null; - ulong num_sub_packets_in_block_minus_one; - ulong *sub_packets_list; - ulong another_null; - ulong timestamp_from_stream; -}; - -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 (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 *); - -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 - -(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? - -(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,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: ------------------------ - -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 |