Mercurial > mplayer.hg
comparison DOCS/tech/libvo2.txt @ 3491:c9aca79b7527
x11control, direct rendering and some minor changes
author | iive |
---|---|
date | Fri, 14 Dec 2001 18:14:27 +0000 |
parents | 8cb0c0a7c415 |
children | 696341879c3c |
comparison
equal
deleted
inserted
replaced
3490:d33dac3fcfa1 | 3491:c9aca79b7527 |
---|---|
6 I'm gonna put this text as attachment to force you to copy only the parts | 6 I'm gonna put this text as attachment to force you to copy only the parts |
7 you want to reply;) | 7 you want to reply;) |
8 | 8 |
9 Best Regards | 9 Best Regards |
10 Ivan Kalvachev | 10 Ivan Kalvachev |
11 | |
12 P.S. This text was included in the DOC/tech/, if you have any suggestion you | |
13 could send them to mplayer developer or advanced users mail lists. If you are | |
14 developer and have CVS access do not delete parts of this document, but you | |
15 could feel free to add paragraphs that you will sign with your name. | |
16 Be warned that the text could be changed, removed, modified, and your name | |
17 could be moved at the top of the document. | |
11 | 18 |
12 1.libvo2 drivers | 19 1.libvo2 drivers |
13 1.1 functions | 20 1.1 functions |
14 Currently these functions are implemented: | 21 Currently these functions are implemented: |
15 init | 22 init |
16 control | 23 control |
17 start | 24 start |
18 stop | 25 stop |
19 get_surface | 26 get_surface |
20 flip_image | 27 flip_image -> we may need to change it's name to show_surface |
21 | 28 |
22 They are simple enough. So I introduce to be implemented and these functions: | 29 They are simple enough. So I introduce to be implemented and these functions: |
23 query | 30 query |
24 update_surface - renamed draw | 31 update_surface - renamed draw |
25 hw_decode | 32 hw_decode |
27 | 34 |
28 Here is detailed description of new functions: | 35 Here is detailed description of new functions: |
29 | 36 |
30 query - the negotiation is more complex than just finding which imgfmt the | 37 query - the negotiation is more complex than just finding which imgfmt the |
31 device could show, we must have list of capabilities, testing modes, etc. | 38 device could show, we must have list of capabilities, testing modes, etc. |
32 this function will have at least 3 modes: | 39 This function will have at least 3 modes: |
33 | |
34 a) return list of available modes with description. | 40 a) return list of available modes with description. |
35 b) check could we use this mode with these parameter. E.g. if we want | 41 b) check could we use this mode with these parameter. E.g. if we want |
36 RGB32 with 3 surfaces for windows image 800x600 we may get out of video | 42 RGB32 with 3 surfaces for windows image 800x600 we may get out of video |
37 memory. We don't want error because this mode could be used with 2 | 43 memory. We don't want error because this mode could be used with 2 |
38 surfaces. | 44 surfaces. |
44 | 50 |
45 update_surface - as in the note above, this is draw function. Why I change | 51 update_surface - as in the note above, this is draw function. Why I change |
46 it's name? I have 2 reasons, first I don't want implementation like vo1, | 52 it's name? I have 2 reasons, first I don't want implementation like vo1, |
47 second it really must update video surface, it must directly call the | 53 second it really must update video surface, it must directly call the |
48 system function that will do it. This function should work only with | 54 system function that will do it. This function should work only with |
49 slices, the size of slice should not be limited and should be passed (e.g | 55 slices, the size of slice should not be limited and should be passed |
50 ystart, yend), if we want draw function, we will call one form libvo2 | 56 (e.g ystart, yend), if we want draw function, we will call one form libvo2 |
51 core, that will call this one with start=0; ymax=Ymax;. Also some system | 57 core, that will call this one with start=0; ymax=Ymax;. Also some system |
52 screen update functions wait for vertical retrace before return, other | 58 screen update functions wait for vertical retrace before return, other |
53 functions just can't handle partial updates. In this case we should inform | 59 functions just can't handle partial updates. In this case we should inform |
54 libvo2 core that device cannot slice, and libvo2 core must take care of | 60 libvo2 core that device cannot slice, and libvo2 core must take care of |
55 the additional buffering. | 61 the additional buffering. |
56 | 62 |
57 hw_decode - to make all dvb,dxr3, tv etc. developers happy. This function | 63 show_surface - this function is used to show the given surface on the screen. |
64 If there is only one surface then it is always visible and this function | |
65 does nothing. | |
66 hw_decode - to make all dvb,dxr3, TV etc. developers happy. This function | |
58 is for you. Be careful, don't OBSEBE it, think and for the future, this | 67 is for you. Be careful, don't OBSEBE it, think and for the future, this |
59 function should have and ability to control HW IDCT, MC that one day will | 68 function should have and ability to control HW IDCT, MC that one day will |
60 be supported and under linux. Be careful:) | 69 be supported and under linux. Be careful:) |
61 | 70 |
62 subpicture - this function will place subtitles. It must be called once to | 71 subpicture - this function will place subtitles. It must be called once to |
65 implementation: we get array of bitmaps. Each one have its own starting | 74 implementation: we get array of bitmaps. Each one have its own starting |
66 x, y and it's own height and width, each one (or all together) could be | 75 x, y and it's own height and width, each one (or all together) could be |
67 in specific imgfmt (spfmt). THE BITMAPS SHOULD NOT OVERLAP! This may not | 76 in specific imgfmt (spfmt). THE BITMAPS SHOULD NOT OVERLAP! This may not |
68 be hw limitation but sw subtitles may get confused if they work as 'c' | 77 be hw limitation but sw subtitles may get confused if they work as 'c' |
69 filter (look my libvo2 core). | 78 filter (look my libvo2 core). |
79 I think that it is good to merge small bitmaps (like characters) in larger | |
80 ones and make all subtitles as one bitmap. The OSD will have another one. | |
81 One more bitmap for and for seek/brightness/contrast/volume bar. | |
70 | 82 |
71 1.2 control() | 83 1.2 control() |
72 OK, here is list of some control()s that I think that could be useful: | 84 OK, here is list of some control()s that I think that could be useful: |
73 SET_ASPECT | 85 SET_ASPECT |
74 SET_SCALLE_X, SET_SIZE_X | 86 SET_SCALLE_X, SET_SIZE_X |
83 Here is description of how these controls to be used: | 95 Here is description of how these controls to be used: |
84 | 96 |
85 SET_ASPECT - this is the move/video aspect, why not calculate it in | 97 SET_ASPECT - this is the move/video aspect, why not calculate it in |
86 different place (mplayer.c) and pass the results to driver by | 98 different place (mplayer.c) and pass the results to driver by |
87 set_size_x/y. First this is only if hardware could scale. Second we may | 99 set_size_x/y. First this is only if hardware could scale. Second we may |
88 need this value if we have TV and we won't calculate new height and width. | 100 need this value if we have TV and we won't calculate any new height and |
101 width. | |
89 | 102 |
90 SET_SCALLE_X/Y - this is to enlarge/downscale the image, it WILL NOT | 103 SET_SCALLE_X/Y - this is to enlarge/downscale the image, it WILL NOT |
91 override SET_ASPECT, they will have cumulative effect, this could be used | 104 override SET_ASPECT, they will have cumulative effect, this could be used |
92 for deinterlacing (HALF SIZE). Second if we want to zoom 200% we don't | 105 for deinterlacing (HALF SIZE). Second if we want to zoom 200% we don't |
93 want to lose aspect calculations. Or better SET_SCALLE to work with | 106 want to lose aspect calculations. Or better SET_SCALLE to work with |
94 current size? | 107 current size? |
95 | 108 |
96 SET_SIZE_X/Y - This is for custom enlarge, to save some scale calculation | 109 SET_SIZE_X/Y - This is for custom enlarge, to save some scale calculation |
97 and for more precise results. | 110 and for more precise results. |
98 | 111 |
99 RESET_SIZE - Set the original size of image, we must call SET_ASPECT agein. | 112 RESET_SIZE - Set the original size of image, we must call SET_ASPECT again. |
100 | 113 |
101 GET/SET_POSOTION_X/Y - This if for windows only, to allow custom move on | 114 GET/SET_POSOTION_X/Y - This if for windows only, to allow custom move on |
102 window. | 115 window. |
103 | 116 |
104 GET/SET_RESOLUTION - change resolution and/or bpp if possible. To be used | 117 GET/SET_RESOLUTION - change resolution and/or bpp if possible. To be used |
105 for window or if we want to change the given resolution of the current | 118 for changing desktop resolution or the resolution of the current |
106 fullscreen mode (NOT TO SET IT just to change it if we don't like it) | 119 fullscreen mode (NOT TO SET IT just to change it if we don't like it) |
107 | 120 |
108 GET/SET_DISPLAY - mainly for X11 and remote displays. Not very useful, but | 121 GET/SET_DISPLAY - mainly for X11 and remote displays. Not very useful, but |
109 may be handy. | 122 may be handy. |
110 | 123 |
112 saturation etc. these and others could be controlled by this. If we want | 125 saturation etc. these and others could be controlled by this. If we want |
113 to query it we must call GET_*, and the to check does our attribute is in | 126 to query it we must call GET_*, and the to check does our attribute is in |
114 there (xv developers be careful, 2 or 3 of default attributes sometimes | 127 there (xv developers be careful, 2 or 3 of default attributes sometimes |
115 are not queried by X, but could be set). | 128 are not queried by X, but could be set). |
116 | 129 |
117 Do you think that TV encodings (NTSC,PAL,SECAM) should have it's own attribute? | 130 Do you think that TV encoding (NTSC,PAL,SECAM) should have it's own attribute? |
118 I would like to hear the GUI developers. Could we separate Mouse/Keyboard | 131 I would like to hear the GUI developers. Could we separate Mouse/Keyboard |
119 from the driver. What info do you need to do it. Don't forget that SDL have | 132 from the driver. What info do you need to do it. Don't forget that SDL have |
120 it's own keyboard/mouse interface. Maybe we should allow video driver to | 133 it's own keyboard/mouse interface. Maybe we should allow video driver to |
121 change the libin driver ? | 134 change the libin driver ? |
122 | 135 |
136 <SOP> | |
137 Arpi wrote: | |
138 I've asked Pontscho (he doesn't understand english well...). | |
139 There is 2 option of GUI<->mplayer interface. | |
140 | |
141 The current, ugly (IMHO) way: | |
142 gui have the control of the video window, it does handle resizing, moving, | |
143 key events etc. all window manipulation in libvo drivers are disabled as gui | |
144 is enabled. it was required as libvo isn't inited and running when gui | |
145 already display the video window. | |
146 | |
147 The wanted way: | |
148 GUI shouldn't control the X window directly, it should use libvo2 control | |
149 calls to resize/move/etc it. But there is a big problem: X cannot be opened | |
150 twice from a process. It means GUI and libvo2 should share the X connection. | |
151 And, as GUI run first (and when file is selected etc then libvo2 is started) | |
152 it should connect to X and later pass the connection to libvo2. It needs an | |
153 extra control() call and some extra code in mplayer.c | |
154 | |
155 but this way gui could work with non-X stuff, like SDL, fbdev (on second | |
156 head for TVout etc), hardware decoders (dvb.dxr3) etc. | |
157 | |
158 as X is so special, libvo2 should have a core function to open/get an X | |
159 connection, and it should be used by all X-based X drivers and gui. | |
160 | |
161 also, GUI needs functions to get mouse and keyboard events, and to | |
162 enable/disable window decoration (title, border). | |
163 | |
164 we need fullscreen switch control function too. | |
165 | |
166 > Maybe we should allow video driver to change the libin driver ? | |
167 forget libin. most input stuff is handled by libvo drivers. | |
168 think of all X stuff (x11,xv,dga,xmga,gl), SDL, aalib, svgalib. | |
169 only a few transparent drivers (fbdev, mga, tdfxfb, vesa) has not, but all | |
170 of them are running on console (and maybe on second head) at fullscreen, so | |
171 they may not need mouse events. console keyboard events are already catched | |
172 and handled by getch2. | |
173 | |
174 I can't see any sense of writing libin. | |
175 | |
176 mpalyer.c should _handle_ all input events, collected from lirc interface, | |
177 getch2, libvo2 etc. and it should set update flags, for gui and osd. | |
178 | |
179 but we should share some plugin code. examples: *_vid code, all common X | |
180 code. it can be either implementing them in libvo2 core (and called from | |
181 plugins) or include these files from all drivers which need it. later method | |
182 is a bit cleaner (from viewpoint of core-plugin independency) but results | |
183 bigger binaries... | |
184 <EOP, Arpi> | |
185 | |
186 Btw. when we finish we will have libin, but it will be spread around mplayer. | |
187 Here is my idea how libin should work: | |
188 1.mplayer sends X connection to libvo2 driver. | |
189 2.libvo2 uses X connection and open window | |
190 3.libvo2 driver opens new libin driver for the newly created window | |
191 4.libin driver sends all commands to mplayer | |
192 5.mplayer collects all commands from opened libin drivers (if more windows are open, lirc, etc) | |
193 In case of SDL we may not skip step 1, may we? | |
194 I just wonder where is the place of OSD in this picture? | |
195 | |
123 1.3. query() | 196 1.3. query() |
124 | 197 |
125 Here come and some attributes for the queried modes, each supported mode | 198 Here come and some attributes for the queried modes, each supported mode |
126 should have such description. It is even possible to have more than one mode | 199 should have such description. It is even possible to have more than one mode |
127 that could display given imgfmt. | 200 that could display given imgfmt. I think that we have to separate window from fullscreen modes and to have yv12 mode for window and yv12 fullscreen mode. |
128 | 201 { |
129 { Scale y/n - hardware scale, do you think that we mast have one for x and | 202 Scale y/n - hardware scale, do you think that we mast have one for x and |
130 one for y (win does)? | 203 one for y (win does)? |
131 | 204 |
132 Fullscreen y/n - if the supported mode is fullscreen, if we have yv12 for | 205 Fullscreen y/n - if the supported mode is fullscreen, if we have yv12 for |
133 fullscreen and window we must threat them as separate modes. Window y/n - | 206 fullscreen and window we must threat them as separate modes. |
134 same as Fullscreen. | 207 |
208 Window y/n - The mode will show the image in a window. Could be removed as | |
209 it is mutually exclusive with Fullscreen | |
135 | 210 |
136 GetSurface y/n - if driver could give us video surface we'll use get_surface() | 211 GetSurface y/n - if driver could give us video surface we'll use get_surface() |
137 | 212 |
138 UpdateSurfece y/n - if driver will update video surface through sys function (X,SDL) | 213 UpdateSurfece y/n - if driver will update video surface through sys function (X,SDL) |
139 | 214 |
149 | 224 |
150 us_clip y/n - if UpdateSurface=yes, this shows could update_surface() | 225 us_clip y/n - if UpdateSurface=yes, this shows could update_surface() |
151 remove strides (when stride> width ), this is used and for cropping. If | 226 remove strides (when stride> width ), this is used and for cropping. If |
152 not, we must do it. | 227 not, we must do it. |
153 | 228 |
154 us_slice y/n - if UpdateSurface=yes, this shows that after executing | 229 us_slice y/n - if UpdateSurface=yes, this shows that update_surface() |
155 update_surface(), the function won't wait for vertical retrace, and we | 230 could draw slices and that after updating surface,it won't wait for |
156 could update surface slice by slice. If us_slice=0 we will have to | 231 vertical retrace, so we could update surface slice by slice. |
157 accumulate all slices in one buffer. | 232 If us_slice==n we will have to accumulate all slices in some buffer. |
158 | 233 |
159 us_upsidedown - if UpdateSufrace=yes, this shows that update_suface() | 234 us_upsidedown - if UpdateSufrace=yes, this shows that update_suface() |
160 could flip the image vertically. In some case this could be united with | 235 could flip the image vertically. In some case this could be united with |
161 us_clip /stride game/ | 236 us_clip /stride tricks/ |
162 | 237 |
163 switch_resoliton y/n - if window=y, this shows could we switch resolution | 238 switch_resoliton y/n - if window=y, this shows could we switch resolution |
164 of desktop, if fullscreen=y, shows that we could change resolution, after | 239 of desktop, if fullscreen==y, shows that we could change resolution, after |
165 we have set the fullscreen mode. | 240 we have set the fullscreen mode. |
166 | 241 |
167 deinterlace y/n - indicates that the device could deinterlace on it's own | 242 deinterlace y/n - indicates that the device could deinterlace on it's own |
168 (radeon, TV). | 243 (radeon, TV). |
169 | 244 |
170 1.4 conclusion | 245 1.4 conclusion |
171 | 246 |
172 As you see, I have removed all additional buffering from the driver. There | 247 As you see, I have removed all additional buffering from the driver. There |
173 is a lot of functionality should be checked and handled by libvo2 core. | 248 is a lot of functionality that should be checked and handled by libvo2 core. |
174 First we should check what else could be added to this draft. Then to check | 249 First we should check what else could be added to this draft. Then to check |
175 all cases and how to handle them. Some of the parameters should be able to | 250 all cases and how to handle them. Some of the parameters should be able to |
176 be overriden by user config, mainly to disable buggy modes or parameters. I | 251 be overridden by user config, mainly to disable buggy modes or parameters. I |
177 belive that this should not be done by command line as there are enough | 252 believe that this should not be done by command line as there are enough |
178 commands now. | 253 commands now. |
179 | 254 |
180 //--------------------------- | 255 //-------------------------------------------------------------------------- |
181 2. libvo2 core | 256 2. libvo2 core |
182 2.1 functions | 257 2.1 functions |
183 now these function are implemented: | 258 now these function are implemented: |
184 init | 259 init |
185 new | 260 new |
200 negotiation will be performed outside libvo2. Replace or find better name. | 275 negotiation will be performed outside libvo2. Replace or find better name. |
201 close -> open/close :) | 276 close -> open/close :) |
202 | 277 |
203 choose_buffering - all buffering must stay hidden. The only exception is for | 278 choose_buffering - all buffering must stay hidden. The only exception is for |
204 hw_decode. In the new implementation this functions is not usable. | 279 hw_decode. In the new implementation this functions is not usable. |
280 It will be replaced with some kind of negotiation. | |
205 draw_slice_start, draw_slice -> if you like it this way, then it's OK. | 281 draw_slice_start, draw_slice -> if you like it this way, then it's OK. |
206 draw_frame -> classic draw function. | 282 draw_frame -> classic draw function. |
207 | 283 |
208 2.2 Minimal buffering | 284 2.2 Minimal buffering |
209 | 285 |
210 I should say that I stand after the idea all buffering, postprocessing, | 286 I should say that I stand after the idea all buffering, postprocessing, |
211 format conversion , sw draw of subtitles, etc to be done in libvo2 core. | 287 format conversion , sw draw of subtitles, etc to be done in libvo2 core. |
212 Why? First this is the only way we could fully control buffering and | 288 Why? First this is the only way we could fully control buffering and |
213 decrease it to minimum. Less buffers means less coping. In some cases this | 289 decrease it to minimum. Less buffers means less coping. In some cases this |
214 could have the opposite effect (mpeg2 with internal buffers in video memory | 290 could have the opposite effect (look at direct rendering). |
215 without HW IDCT, MC, or if we have unaligned write). | |
216 | 291 |
217 The first step of the analyse is to find out what we need: | 292 The first step of the analyse is to find out what we need: |
218 | 293 |
219 DECODER - type_of_buffer:{internal/static/normal}, | 294 DECODER - num_out_buffers={1/2/3/...} |
295 { | |
296 buffer_type:{fixed/static/movable} | |
297 read_only:{yes/no} | |
298 } * (num_out_buffers) | |
220 slice:{not/supported} | 299 slice:{not/supported} |
221 | 300 |
222 FILTER 1..x - processing:{ c-copy(buff1,buff2), p-process(buff1) }, | 301 FILTER 1..x - processing:{ c-copy(buff1,buff2), p-process(buff1) }, |
223 slice:{not/supported} | 302 slice:{not/supported} |
224 write_combine:{not/safe}, | 303 write_combine:{not/safe}, |
229 write_combine:{not/safe}, | 308 write_combine:{not/safe}, |
230 clip:{can/not}, | 309 clip:{can/not}, |
231 upsidedown:(can/not), | 310 upsidedown:(can/not), |
232 surfaces:{1/2/3,..,n} | 311 surfaces:{1/2/3,..,n} |
233 | 312 |
234 If we want direct rendering we need normal buffer, no filters, and (at | |
235 least) 2 video surfaces. (we may allow 'p' filter like subtitles). | |
236 | |
237 If we have static buffer, we have 2 choices: to render in 1 surface | |
238 (visual flickering) or to make additional buffering and draw on flip_page | |
239 (like in libvo1). | |
240 | 313 |
241 Here I introduce and one letter codes that I use for analyse. | 314 Here I introduce and one letter codes that I use for analyse. |
242 Details: | 315 Details: |
243 | 316 |
244 DECODER - We always get buffer from the decoder, some decoders could give | 317 DECODER - We always get buffer from the decoder, some decoders could give |
245 pointer to it's internal buffers, other takes pointers to buffers where | 318 pointer to it's internal buffers, other takes pointers to buffers where |
246 they should store the final image. Some decoders could call draw_slice | 319 they should store the final image. Some decoders could call draw_slice |
247 after they have finished with some portion of the image. | 320 after they have finished with some portion of the image. |
248 | 321 |
249 type_of_buffer - I take this from the current libvo2 spec. I call 'I' | 322 num_out_buffers - number of output buffers. Each one could have it's own |
250 internal buffer (readonly), 'K' static buffer(one,constant pointer), and | 323 parameters. In the usual case there will be only one buffer. Some |
251 'B' - normal buffer. | 324 decoders may have 2 internal buffers like odivx, or like mpeg12 - 3 buffers |
325 of different types(2 static and 1 temp). | |
326 | |
327 buffer_type - | |
328 - fixed - we don't have control where the buffer will be. We could | |
329 just take pointer to this buffer. No direct rendering is possible. | |
330 - static - we could set this buffer but then we can't change it's position. | |
331 - movable - we could set this buffer to any location at any time. | |
332 read_only - the data in this buffer will be used in future so we must not | |
333 try to write in there or we'll corrupt the video. If we have any 'p' kind | |
334 of filter we'll make copy. | |
252 | 335 |
253 slice - this flag shows that decoder knows and want to work with slices. | 336 slice - this flag shows that decoder knows and want to work with slices. |
254 | 337 |
255 FILTER - postprocessing, sw drawing subtitles, format conversion, crop, | 338 FILTER - postprocessing, sw drawing subtitles, format conversion, crop, |
256 additional filters. | 339 external filters. |
257 | 340 |
258 slice - could this filter work with slice order. We could use slice even | 341 slice - could this filter work with slice order. We could use slice even |
259 when decoder does not support slice, we just need 2 or more filters that | 342 when decoder does not support slice, we just need 2 or more filters that |
260 does. This could give us remarkable speed boost. | 343 does. This could give us remarkable speed boost. |
261 | 344 |
262 processing - some filters can copy the image from one buffer to the other, | 345 processing - some filters can copy the image from one buffer to the other, |
263 I call them 'c', convert and crop(stride copy) are good examples but don't | 346 I call them 'c', convert and crop(stride copy) are good examples but don't |
264 forget simple 1:1 copy. Other filters does process only part if the image, | 347 forget simple 1:1 copy. Other filters does process only part if the image, |
265 and could reuse the given buffer, e.g. putting subtitles. Other filters | 348 and could reuse the given buffer, e.g. putting subtitles. I call them 'p' |
266 could work in one buffer, but could work and with 2, I call them 't' | 349 Other filters could work in one buffer, but could work and with 2, I call |
267 class, after analyse they will fade to 'c' or 'p'. | 350 them 't' class, after analyse they will fade to 'c' or 'p'. |
268 | 351 |
269 runtime_remove - postprocess with autoq. Subtitles appear and disappear, | 352 runtime_remove - postprocess with autoq. Subtitles appear and disappear, |
270 should we copy image from one buffer to another if there is no processing | 353 should we copy image from one buffer to another if there is no processing |
271 at all? | 354 at all? |
272 | 355 |
274 be able to remove them and to make some tricks like crop and upside_down. | 357 be able to remove them and to make some tricks like crop and upside_down. |
275 | 358 |
276 VIDEO_OUT - take a look of libvo2 driver I propose. | 359 VIDEO_OUT - take a look of libvo2 driver I propose. |
277 method - If we get surface -'S'. If we use draw* (update_surface) - 'd' | 360 method - If we get surface -'S'. If we use draw* (update_surface) - 'd' |
278 | 361 |
279 As you may see hd_decode don't have complicated buffering:) | 362 As you may see hw_decode don't have complicated buffering:) |
280 I make the analyse this way. First I put decoder buffer, then I put all | 363 I make the analyse this way. First I put decoder buffer, then I put all |
281 filters, that may be needed, and finally I put video out method. | 364 filters, that may be needed, and finally I put video out method. |
282 | 365 |
283 2.3. Rules for minimal buffering | 366 2.3. Rules for minimal buffering |
284 The rules are these: | 367 A) Direct rendering. |
285 The 'p' filters process in the buffer of the left, if we have 'I' buffer | 368 Direct rendering means that the decoder will use video surface as output buffer. |
286 then insert copy and new 'B' buffer. | 369 Most of the decoders have internal buffers and on request they copy |
287 With 'c' filter we must make sure that we have buffer ('B' or 'S') from the right(->) side. | 370 the ready image from one of them to given location, as we can't get pointer |
288 We must take care that, if we have S we need to finish with copy ('c'), and | 371 to the internal buffer the fastest way is to give video surface as |
289 if we have 'd' we must end with some kind of buffer. | 372 output buffer and the decoder will draw it for us. This is safe as most of |
373 copy routines are optimised for double words aligned access. | |
374 If we get internal buffer, we could copy the image on our own. This is not | |
375 direct rendering but it gets the same speed. If fact that's why -vc odivx | |
376 is faster that -vc divx4 while they use the same divx4linux library. | |
377 Sometimes it's possible to set video surface as internal buffer, but in most | |
378 cases the decoding process is byte oriented and many unaligned access is | |
379 performed. Moreover, reading from video memory on some cards is extremely | |
380 slow, about 4 times and more (and this is without setting MTRR), but some | |
381 decoders could take advantage of this. In the best case (reading performed | |
382 from the cache and using combined write ) we'll watch DivX movie with the same | |
383 speed as DivX4 is skipping frames. | |
384 | |
385 What does we need for Direct Rendering? | |
386 1. We should be able to get video surfaces. | |
387 2. The decoder should have at least one buffer with buffer_type != fixed. | |
388 3. If we have 'c' filter we can not use direct rendering. If we have | |
389 'p' filter we may allow it. | |
390 4. If decoder have one static buffer, then we are limited to 1 video surface. | |
391 In this case we will see how the frame is rendered (ugly refresh in best case) | |
392 4. Each static buffer and each read_only buffer needs to have it own | |
393 video surface. If we don't have enough ... well we may make some tricks | |
394 but it is too complicated //using direct rendering for the first in | |
395 the list and the rest will use memory buffering. And we must have free | |
396 video surfaces for the rest of decoder buffers// | |
397 5. Normal (buffer_type=movable, read_only=no) buffer could be redirected to | |
398 any available video surface. | |
399 | |
400 B) The usual case libvo2 core takes responsibility to move the data. It mast | |
401 follow these rules: | |
402 The 'p' filters process in the buffer of the left, if we have read_only | |
403 buffer then we must copy the buffer content in temp buffer. | |
404 With 'c' filter we must make sure that we have buffer on the right(->) side. | |
290 In the usual case 't' are replaced with 'p' except when 't' is before 'S'. | 405 In the usual case 't' are replaced with 'p' except when 't' is before 'S'. |
291 If we have 'B S' or 'K S' we may make direct rendering and remove the 'B' or 'K' buffer. | 406 We must have at least one 'c' if we have to make crop, clip, or flip image |
292 We must have at least one 'c' if we have to make crop, clip, or flip image upside down. | 407 upside down. |
293 Take care for the additional buffering when we have 1 surface (the libvo1 way). | 408 Take care for the additional buffering when we have 1 surface (the libvo1 way). |
294 Be aware that some filters must be before other. E.g. Postporcessing should | 409 Be aware that some filters must be before other. E.g. Postporcessing should |
295 be before subtitles:) | 410 be before subtitles:) |
296 If we want scale (-zoom), and vo2 driver can't make it then add and scale | 411 If we want scale (-zoom), and vo2 driver can't make it then add and scale |
297 filter 'c'. For better understanding I have one convert filter that can | 412 filter 'c'. For better understanding I have only one convert filter that can |
298 copy, convert, convert and scale. The only thing that is missing now is | 413 copy, convert, scale, convert and scale. In mplayer it really will be only |
299 simple scale (yv12). | 414 one filter. |
300 | 415 |
301 I have made grammar for these cases but it is too big and I hope that | |
302 something cleverer could be made. Don't think that having only 3 filters | |
303 (postporcess, convert/copy, subtitles) may make the things simpler. This | |
304 algorithm could be used and for numerous filters used in encoders. | |
305 | 416 |
306 2.4 Negotiation | 417 2.4 Negotiation |
307 Few words about negotiation. It is hard thing to find the best mode. Here is | 418 Few words about negotiation. It is hard thing to find the best mode. Here is |
308 algorithm that could find the best mode. But first I must say that we need | 419 algorithm that could find the best mode. But first I must say that we need |
309 some kind of weight for the filters and drawing. I think that we could use | 420 some kind of weight for the filters and drawing. I think that we could use |
316 always at maximum filters!! | 427 always at maximum filters!! |
317 4. Compare the results. | 428 4. Compare the results. |
318 | 429 |
319 I may say that we don't need automatic codec selection as now we could put | 430 I may say that we don't need automatic codec selection as now we could put |
320 best codecs at beginning of codecs.conf as it is now. We may need to make | 431 best codecs at beginning of codecs.conf as it is now. We may need to make |
321 same thing with videodrv.conf :) | 432 the same thing with videodrv.conf. Or better make config files with preferred |
322 | 433 order of decoders and video modes:) |
323 | 434 |
324 |