mirror of
https://github.com/mpv-player/mpv
synced 2025-03-31 15:59:34 +00:00
some updates, fixes discovered by me
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@6351 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
arpi
parent
56ae80d6e4
commit
76538ed792
DOCS/tech/realcodecs
@ -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 :)
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user