Mercurial > mplayer.hg
comparison DOCS/tech/dr-methods.txt @ 4994:e74227031a12
dr + libmpcodecs
author | arpi |
---|---|
date | Fri, 08 Mar 2002 20:17:33 +0000 |
parents | |
children | f0cb56e4e986 |
comparison
equal
deleted
inserted
replaced
4993:53c569d36b2c | 4994:e74227031a12 |
---|---|
1 DIRECT RENDERING METHODS -- by A'rpi | |
2 ======================== (based on a mail to -dev-eng) | |
3 | |
4 Ok. It seems none of you really knows what direct rendering means... | |
5 I'll try to explain now! :) | |
6 | |
7 At first, there are 2 different way, both called direct rendering. | |
8 The main point is the same, but they work different. | |
9 | |
10 method 1: decoding directly to externally provided buffers. | |
11 so, the codec decodes macroblocks directly to the buffer provided by teh | |
12 caller. as this buffer will be readed later (for MC of next frame) it's not | |
13 a good idea to place such buffers in slow video ram. but. | |
14 there are many video out drivers using buffers in system ram, and using some | |
15 way of memcpy or DMA to blit it to vieo ram at display time. | |
16 for example, Xv and X11 (normal and Shm too) are such thingie. | |
17 XImage will be a buffer in system ram (!) and X*PutImage will copy it to | |
18 video ram. Only nvidia and ati rage128 Xv drivers use DMA, others just | |
19 memcpy it. Also some opengl drivers (including Matrox) uses DMA to copy from | |
20 subteximage to video ram. | |
21 The current mpalyer way mean: codec allocates some buffer, and decode image | |
22 to that buffer. then this buffer is copied to X11's buffer. then Xserver | |
23 copies this buffer to video ram. So one more memcpy than required... | |
24 direct rendering can remove this extar memcpy, and use the Xserver's memory | |
25 buffers for decoding buffer. Note again: it helps only if the external | |
26 buffer is in fast system ram. | |
27 | |
28 method 2: decoding to internal buffers, but blit after each macroblocks, | |
29 including optional colorspace conversion. | |
30 advantages: it can blit into video ram, as it keeps the copy in its internal | |
31 buffers for next frame's MC. skipped macroblocks won't be copied again to | |
32 video ram (except if video buffer address changes between frames -> hw | |
33 double/triple buffering) | |
34 Just avoiding blitting of skipped MBs mean about 100% speedup (2 times | |
35 faster) for low bitrate (<700kbit) divxes. It even makes possible to watch | |
36 VCD resolution divx on p200mmx with DGA. | |
37 how does it work? the codec works as normally, decodes macroblocks into its | |
38 internal buffer. but after each decoded macroblock, it immediatelly copies | |
39 this macroblock to the video ram. it's in the L1 cache, so it will be fast. | |
40 skipped macroblocks can be skipped easily -> less vram write -> more speedup. | |
41 but, as it copies directly to video ram, it must do colorspace conversion if | |
42 needed (for example divx -> rgb DGA), and cannot be used with scaling. | |
43 another interesting question of such direct rendering is the planar formats. | |
44 Eugene K. of Divx4 told me that he experienced worse performance blittig | |
45 yv12 blocks (copied 3 blocks to 3 different (Y,U,V) buffers) than doing | |
46 (really unneeded) yv12->yuy2 conversion on-the-fly. | |
47 so, divx4 codec (with -vc divx4 api) converts from its internal yv12 buffer | |
48 to the external yuy2. | |
49 | |
50 libmpeg2 already uses simplified variation of this: when it finish decoding a | |
51 slice (a horizontal line of MBs) it copies it to external (video ram) buffer | |
52 (using callback to libvo), so at least it copies from L2 cache instead of | |
53 slow ram. it gave me 23% -> 20% VOB decoding speedup on p3. | |
54 | |
55 so, again: the main difference between method 1 and 2: | |
56 method1 stores decoded data only once: in the external read/write buffer. | |
57 method2 stores decoded data twice: in its internal read/write buffer (for | |
58 later reading) and in the write-only slow video ram. | |
59 | |
60 both methods can make big speedup, depending on codec behaviour and libvo | |
61 driver. for example, IPB mpegs could combine these, use method 2 for I/P | |
62 frames and method 1 for B frams. mpeg2dec does already this. | |
63 for I-only type video (like mjpeg) method 1 is better. for I/P type video | |
64 with MC (like divx, h263 etc) method 2 is the best choice. | |
65 for I/P type videos without MC (like FLI, CVID) could use method 1 with | |
66 static buffer or method 2 with double/triple buffering. | |
67 | |
68 i hope it is clear now. | |
69 and i hope even nick understand what are we talking about... | |
70 | |
71 ah, and at the end, the abilities of codecs: | |
72 libmpeg2: can do method 1 and 2 (but slice level copy, not MB level) | |
73 vfw, dshow: can do method 2, with static or variable address external buffer | |
74 odivx, and most native codecs like fli, cvid, rle: can do method 1 | |
75 divx4: can do method 2 (with old odivx api it does method 1) | |
76 libavcodec, xanim: they currently can't do DR, but they exports their | |
77 internal buffers. but it's very easy to implement menthod 1 support, | |
78 and a bit harder but possible without any rewrite to do method 2. | |
79 | |
80 so, dshow and divx4 already implements all requirements of method 2. | |
81 libmpeg2 implements method 1, and it's easy to add to libavcodec. | |
82 | |
83 anyway, in the ideal world, we need all codecs support both methods. | |
84 anyway 2: in ideal world, there are no libvo drivers having buffer in system | |
85 ram and memcpy to video ram... | |
86 anyway 3: in our really ideal world, all libvo driver has its buffers in | |
87 fast sytem ram and does blitting with DMA... :) | |
88 | |
89 ============================================================================ | |
90 MPlayer NOW! -- The libmpcodecs way. | |
91 | |
92 libmpcodecs replaced old draw callbacks with mpi (mplayer image) struct. | |
93 steps of decoding with libmpcodecs: | |
94 1. codec requests an mpi from libmpcodecs core (vd.c) | |
95 2. vd creates an mpi struct filled by codec's requirements (size, stride, | |
96 colorspace, flags, type) | |
97 3. vd asks libvo (control(VOCTRL_GET_IMAGE)), if it can provide such buffer: | |
98 - if it can -> do direct rendering | |
99 - it it can not -> allocate system ram area with memalign()/malloc() | |
100 Note: codec may request EXPORT buffer, it means buffer allocation is | |
101 done inside the codec, so we cannot do DR :( | |
102 4. codec decodes frame to the mpi struct (system ram or direct rendering) | |
103 5. if it isn't DR, we call libvo's draw functions to blit image to video ram | |
104 | |
105 current possible buffer setups: | |
106 - EXPORT - codec handles buffer allocation and it exports its buffer pointers | |
107 used for opendivx, xanim and libavcodec | |
108 - STATIC - codec requires a single static buffer with constant preserved content | |
109 used by codecs which do partial updating of image, but doesn't require reading | |
110 of previous frame. most rle-based codecs, like cvid, rle8, qtrle, qtsmc etc. | |
111 - TEMP - codec requires a buffer, but it doesn't depend on previous frame at all | |
112 used for I-only codecs (like mjpeg) and for codecs supporting method-2 direct | |
113 rendering with variable buffer address (vfw, dshow, divx4). | |
114 - IP - codec requires 2 (or more) read/write buffers. it's for codecs supporting | |
115 method-1 direct rendering but using motion compensation (ie. reading from | |
116 previous frame buffer). could be used for libavcodec (divx3/4,h263) later. | |
117 IP buffer stays from 2 (or more) STATIC buffers. | |
118 - IPB - similar to IP, but also have one (or more) TEMP buffers for B frames. | |
119 it will be used for libmpeg2 and libavcodec (mpeg1/2/4). | |
120 IPB buffer stays from 2 (or more) STATIC buffers and 1 (or more) TEMP buffer. |