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: