← Back to branch summary

~gma500/+junk/emgd160

« back to all changes in this revision

Viewing changes to mplayer-vaapi/DOCS/tech/realcodecs/streaming.txt

  • Committer: Luca Forina
  • Date: 2011-05-03 09:34:53 UTC
  • Revision ID: luca.forina@gmail.com-20110503093453-p1l4o1ck3g67vrha
added mplayer-vaapi

Show diffs side-by-side

added added

removed removed

Lines of Context:
mplayer-vaapi/DOCS/tech/realcodecs/streaming.txt
 
1
In the RV30 format, another encapsulated data layer for the video stream
 
2
has been introduced. In lack of a name I'll call them sub packets, the
 
3
normal packets which exist in RV10 I'll call - well - packets. The stream
 
4
of bytes which is put in one memory block is named block.
 
5
 
 
6
The format extension has been * by wild guessing and comparing the
 
7
received data between the original viewer and the demuxer.
 
8
 
 
9
 
 
10
 
 
11
Every packet may contain one or more sub packets, and one block may
 
12
be contained inside one or more adjacent (sub) packets.
 
13
A sub packet (fragment) starts with a small header (two letters are one byte):
 
14
 
 
15
 
 
16
aa(bb)[cccc{gggg}dddd{eeee}ff]
 
17
 
 
18
aa:   indicates the type of header
 
19
      the 2MSB indicate the header type (mask C0)
 
20
      C0:      the [] part exists, but not () -> whole packet (not fragmented)
 
21
      00, 80:  the data block is encapsulated inside multiple packets.
 
22
               bb contains the sequence number, beginning with 1.
 
23
               80 indicates the last sub packet containing data for the
 
24
               current block. no C0 or 40 sub packet follows until
 
25
               the block has been finished with a 80 sub packet.
 
26
               No packet with another stream than the current video stream
 
27
               is inside the sub packet chain, at least I haven't seen
 
28
               such case - the demuxer will shout in this case.
 
29
      40:      [] does not exist, the meaning of bb is unknown to me
 
30
               data follows to the end of the packet
 
31
      mask 3F: unknown
 
32
bb:   sub-seq - mask 0x7f: the sequence number of the _fragment_
 
33
                mask 0x80: unknown, seems to alternating between 00 and 80
 
34
cccc: mask 3FFF: _total_ length of the packet
 
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...
 
38
dddd: when it's 0, {} exists (only in this case)
 
39
      mask 3FFF: offset of fragment inside the whole packet. it's counted
 
40
                 from the beginning of the packet, except when hdr&0x80,
 
41
                 hten it's relative to the _end_ of the packet, so it's
 
42
                 equal to fragment size!
 
43
      mask C000: like cccc, except the first case (always 4000)
 
44
      when it's all 0000, it indicates value >=0x4000, you should read {eeee}
 
45
      and use all 16 bits of it. dunno what happens when length>=65536...
 
46
ff:   sequence number of the assembled (defragmented) packets, beginning with 0
 
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.
 
50
 
 
51
 
 
52
packet header:
 
53
 
 
54
ushort unknown
 
55
ulong  blocksize
 
56
ushort streamid
 
57
uchar  reserved
 
58
uchar  flags 1=reliable, 2=keyframe