Mercurial > mplayer.hg
comparison DOCS/tech/realcodecs/streaming.txt @ 6350:a2173ca2f49c
some updates, fixes discovered by me
author | arpi |
---|---|
date | Sun, 09 Jun 2002 03:25:28 +0000 |
parents | c09a890e4c8c |
children | 32725ca88fed |
comparison
equal
deleted
inserted
replaced
6349:c09a890e4c8c | 6350:a2173ca2f49c |
---|---|
8 | 8 |
9 | 9 |
10 | 10 |
11 Every packet may contain one or more sub packets, and one block may | 11 Every packet may contain one or more sub packets, and one block may |
12 be contained inside one or more adjacent (sub) packets. | 12 be contained inside one or more adjacent (sub) packets. |
13 A sub packet starts with a small header (two letters are one byte): | 13 A sub packet (fragment) starts with a small header (two letters are one byte): |
14 | 14 |
15 | 15 |
16 aa(bb)[ccccdddd{eeee}ff] | 16 aa(bb)[cccc{gggg}dddd{eeee}ff] |
17 | 17 |
18 aa: indicates the type of header | 18 aa: indicates the type of header |
19 the 2MSB indicate the header type (mask C0) | 19 the 2MSB indicate the header type (mask C0) |
20 C0: the [] part exists, but not () | 20 C0: the [] part exists, but not () -> whole packet (not fragmented) |
21 00, 80: the data block is encapsulated inside multiple packets. | 21 00, 80: the data block is encapsulated inside multiple packets. |
22 bb contains the sequence number, beginning with 1. | 22 bb contains the sequence number, beginning with 1. |
23 80 indicates the last sub packet containing data for the | 23 80 indicates the last sub packet containing data for the |
24 current block. no C0 or 40 sub packet follows until | 24 current block. no C0 or 40 sub packet follows until |
25 the block has been finished with a 80 sub packet. | 25 the block has been finished with a 80 sub packet. |
27 is inside the sub packet chain, at least I haven't seen | 27 is inside the sub packet chain, at least I haven't seen |
28 such case - the demuxer will shout in this case. | 28 such case - the demuxer will shout in this case. |
29 40: [] does not exist, the meaning of bb is unknown to me | 29 40: [] does not exist, the meaning of bb is unknown to me |
30 data follows to the end of the packet | 30 data follows to the end of the packet |
31 mask 3F: unknown | 31 mask 3F: unknown |
32 bb: unknown | 32 bb: sub-seq - mask 0x7f: the sequence number of the _fragment_ |
33 cccc: mask 3FFF: length of data | 33 mask 0x80: unknown, seems to alternating between 00 and 80 |
34 cccc: mask 3FFF: _total_ length of the packet | |
34 mask C000: unknown, seems to be always 4000 | 35 mask C000: unknown, seems to be always 4000 |
36 when it's all 0000, it indicates value >=0x4000, you should read {gggg} | |
37 and use all 16 bits of it. dunno what happens when length>=65536... | |
35 dddd: when it's 0, {} exists (only in this case) | 38 dddd: when it's 0, {} exists (only in this case) |
36 mask 3FFF: I thought it would have been the offset inside the | 39 mask 3FFF: offset of fragment inside the whole packet. it's counted |
37 block, is not correct in every case. Just appending the | 40 from the beginning of the packet, except when hdr&0x80, |
38 data works better, ignoring it. | 41 hten it's relative to the _end_ of the packet, so it's |
39 mask C000: like cccc, except the first case | 42 equal to fragment size! |
40 eeee: only exists when dddd exists and is zero. contains the data | 43 mask C000: like cccc, except the first case (always 4000) |
41 dddd should contain in the second case. don't know what the developers | 44 when it's all 0000, it indicates value >=0x4000, you should read {eeee} |
42 had in mind. | 45 and use all 16 bits of it. dunno what happens when length>=65536... |
43 ff: sequence number for the data blocks, beginning with 0 | 46 ff: sequence number of the assembled (defragmented) packets, beginning with 0 |
44 | 47 |
48 NOTE: the demuxer should build a table of the subpacket offsets relative to the | |
49 start of whole packet, it's required by the rv20/rv30 video decoders. | |
45 | 50 |
46 | 51 |
47 packet header: | 52 packet header: |
48 | 53 |
49 ushort unknown | 54 ushort unknown |