Merge branch 'for-linus' of git://git.infradead.org/users/eparis/selinux into for...
[pandora-kernel.git] / Documentation / video4linux / Zoran
1 Frequently Asked Questions:
2 ===========================
3 subject: unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
4 website: http://mjpeg.sourceforge.net/driver-zoran/
5
6 1. What cards are supported
7 1.1 What the TV decoder can do an what not
8 1.2 What the TV encoder can do an what not
9 2. How do I get this damn thing to work
10 3. What mainboard should I use (or why doesn't my card work)
11 4. Programming interface
12 5. Applications
13 6. Concerning buffer sizes, quality, output size etc.
14 7. It hangs/crashes/fails/whatevers! Help!
15 8. Maintainers/Contacting
16 9. License
17
18 ===========================
19
20 1. What cards are supported
21
22 Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
23 DC10/DC10+/DC30/DC30+ and related boards (available under various names).
24
25 Iomega Buz:
26 * Zoran zr36067 PCI controller
27 * Zoran zr36060 MJPEG codec
28 * Philips saa7111 TV decoder
29 * Philips saa7185 TV encoder
30 Drivers to use: videodev, i2c-core, i2c-algo-bit,
31                 videocodec, saa7111, saa7185, zr36060, zr36067
32 Inputs/outputs: Composite and S-video
33 Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
34 Card number: 7
35
36 AverMedia 6 Eyes AVS6EYES:
37 * Zoran zr36067 PCI controller
38 * Zoran zr36060 MJPEG codec
39 * Samsung ks0127 TV decoder
40 * Conexant bt866  TV encoder
41 Drivers to use: videodev, i2c-core, i2c-algo-bit,
42                 videocodec, ks0127, bt866, zr36060, zr36067
43 Inputs/outputs: Six physical inputs. 1-6 are composite,
44                 1-2, 3-4, 5-6 doubles as S-video,
45                 1-3 triples as component.
46                 One composite output.
47 Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
48 Card number: 8
49 Not autodetected, card=8 is necessary.
50
51 Linux Media Labs LML33:
52 * Zoran zr36067 PCI controller
53 * Zoran zr36060 MJPEG codec
54 * Brooktree bt819 TV decoder
55 * Brooktree bt856 TV encoder
56 Drivers to use: videodev, i2c-core, i2c-algo-bit,
57                 videocodec, bt819, bt856, zr36060, zr36067
58 Inputs/outputs: Composite and S-video
59 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
60 Card number: 5
61
62 Linux Media Labs LML33R10:
63 * Zoran zr36067 PCI controller
64 * Zoran zr36060 MJPEG codec
65 * Philips saa7114 TV decoder
66 * Analog Devices adv7170 TV encoder
67 Drivers to use: videodev, i2c-core, i2c-algo-bit,
68                 videocodec, saa7114, adv7170, zr36060, zr36067
69 Inputs/outputs: Composite and S-video
70 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
71 Card number: 6
72
73 Pinnacle/Miro DC10(new):
74 * Zoran zr36057 PCI controller
75 * Zoran zr36060 MJPEG codec
76 * Philips saa7110a TV decoder
77 * Analog Devices adv7176 TV encoder
78 Drivers to use: videodev, i2c-core, i2c-algo-bit,
79                 videocodec, saa7110, adv7175, zr36060, zr36067
80 Inputs/outputs: Composite, S-video and Internal
81 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
82 Card number: 1
83
84 Pinnacle/Miro DC10+:
85 * Zoran zr36067 PCI controller
86 * Zoran zr36060 MJPEG codec
87 * Philips saa7110a TV decoder
88 * Analog Devices adv7176 TV encoder
89 Drivers to use: videodev, i2c-core, i2c-algo-bit,
90                 videocodec, sa7110, adv7175, zr36060, zr36067
91 Inputs/outputs: Composite, S-video and Internal
92 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
93 Card number: 2
94
95 Pinnacle/Miro DC10(old): *
96 * Zoran zr36057 PCI controller
97 * Zoran zr36050 MJPEG codec
98 * Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
99 * Micronas vpx3220a TV decoder
100 * mse3000 TV encoder or Analog Devices adv7176 TV encoder *
101 Drivers to use: videodev, i2c-core, i2c-algo-bit,
102                 videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
103 Inputs/outputs: Composite, S-video and Internal
104 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
105 Card number: 0
106
107 Pinnacle/Miro DC30: *
108 * Zoran zr36057 PCI controller
109 * Zoran zr36050 MJPEG codec
110 * Zoran zr36016 Video Front End
111 * Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
112 * Analog Devices adv7176 TV encoder
113 Drivers to use: videodev, i2c-core, i2c-algo-bit,
114                 videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
115 Inputs/outputs: Composite, S-video and Internal
116 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
117 Card number: 3
118
119 Pinnacle/Miro DC30+: *
120 * Zoran zr36067 PCI controller
121 * Zoran zr36050 MJPEG codec
122 * Zoran zr36016 Video Front End
123 * Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
124 * Analog Devices adv7176 TV encoder
125 Drivers to use: videodev, i2c-core, i2c-algo-bit,
126                 videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
127 Inputs/outputs: Composite, S-video and Internal
128 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
129 Card number: 4
130
131 Note: No module for the mse3000 is available yet
132 Note: No module for the vpx3224 is available yet
133 Note: use encoder=X or decoder=X for non-default i2c chips
134
135 ===========================
136
137 1.1 What the TV decoder can do an what not
138
139 The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
140 information is not enough. There are several formats of the TV standards.
141 And not every TV decoder is able to handle every format. Also the every
142 combination is supported by the driver. There are currently 11 different
143 tv broadcast formats all aver the world.
144
145 The CCIR defines parameters needed for broadcasting the signal.
146 The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
147 The CCIR says not much about the colorsystem used !!!
148 And talking about a colorsystem says not to much about how it is broadcast.
149
150 The CCIR standards A,E,F are not used any more.
151
152 When you speak about NTSC, you usually mean the standard: CCIR - M using
153 the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
154 and a few others.
155
156 When you talk about PAL, you usually mean: CCIR - B/G using the PAL
157 colorsystem which is used in many Countries.
158
159 When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
160 which is used in France, and a few others.
161
162 There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
163 Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
164
165 The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
166 Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
167
168 The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
169 Ireland, Nigeria, South Africa.
170
171 The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
172 and is used in Argentinia, Uruguay, an a few others
173
174 We do not talk about how the audio is broadcast !
175
176 A rather good sites about the TV standards are:
177 http://www.sony.jp/support/
178 http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
179 and http://www.cabl.com/restaurant/channel.html
180
181 Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
182 used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
183 as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
184 be the same as NTSC 4.43.
185 NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
186 to split coma and luma instead of a Delay line.
187
188 But I did not defiantly find out what NTSC Comb is.
189
190 Philips saa7111 TV decoder
191 was introduced in 1997, is used in the BUZ and
192 can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
193
194 Philips saa7110a TV decoder
195 was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
196 can handle: PAL B/G, NTSC M and SECAM
197
198 Philips saa7114 TV decoder
199 was introduced in 2000, is used in the LML33R10 and
200 can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
201
202 Brooktree bt819 TV decoder
203 was introduced in 1996, and is used in the LML33 and
204 can handle: PAL B/D/G/H/I, NTSC M
205
206 Micronas vpx3220a TV decoder
207 was introduced in 1996, is used in the DC30 and DC30+ and
208 can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
209
210 Samsung ks0127 TV decoder
211 is used in the AVS6EYES card and
212 can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM
213
214 ===========================
215
216 1.2 What the TV encoder can do an what not
217
218 The TV encoder are doing the "same" as the decoder, but in the oder direction.
219 You feed them digital data and the generate a Composite or SVHS signal.
220 For information about the colorsystems and TV norm take a look in the
221 TV decoder section.
222
223 Philips saa7185 TV Encoder
224 was introduced in 1996, is used in the BUZ
225 can generate: PAL B/G, NTSC M
226
227 Brooktree bt856 TV Encoder
228 was introduced in 1994, is used in the LML33
229 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
230
231 Analog Devices adv7170 TV Encoder
232 was introduced in 2000, is used in the LML300R10
233 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
234
235 Analog Devices adv7175 TV Encoder
236 was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
237 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
238
239 ITT mse3000 TV encoder
240 was introduced in 1991, is used in the DC10 old
241 can generate: PAL , NTSC , SECAM
242
243 Conexant bt866 TV encoder
244 is used in AVS6EYES, and
245 can generate: NTSC/PAL, PAL­M, PAL­N
246
247 The adv717x, should be able to produce PAL N. But you find nothing PAL N
248 specific in the registers. Seem that you have to reuse a other standard
249 to generate PAL N, maybe it would work if you use the PAL M settings.
250
251 ==========================
252
253 2. How do I get this damn thing to work
254
255 Load zr36067.o. If it can't autodetect your card, use the card=X insmod
256 option with X being the card number as given in the previous section.
257 To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
258
259 To automate this, add the following to your /etc/modprobe.conf:
260
261 options zr36067 card=X1[,X2[,X3[,X4[..]]]]
262 alias char-major-81-0 zr36067
263
264 One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
265 just automates loading. If you start using xawtv, the device won't load on
266 some systems, since you're trying to load modules as a user, which is not
267 allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
268 XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
269 one of your startup scripts (normally rc.local) if you don't use X. Both
270 make sure that the modules are loaded on startup, under the root account.
271
272 ===========================
273
274 3. What mainboard should I use (or why doesn't my card work)
275
276 <insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
277
278 Experience tells us that people with a Buz, on average, have more problems
279 than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
280 based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
281 based on a different chipset. Here's some notes from Andrew Stevens:
282 --
283 Here's my experience of using LML33 and Buz on various motherboards:
284
285 VIA MVP3
286         Forget it. Pointless. Doesn't work.
287 Intel 430FX (Pentium 200)
288         LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
289 Intel 440BX (early stepping)
290         LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
291 Intel 440BX (late stepping)
292         Buz tolerable, LML3 almost perfect (occasional single frame drops)
293 SiS735
294         LML33 perfect, Buz tolerable.
295 VIA KT133(*)
296         LML33 starting to get annoying, Buz poor enough that I have up.
297
298 Both 440BX boards were dual CPU versions.
299 --
300 Bernhard Praschinger later added:
301 --
302 AMD 751
303         Buz perfect-tolerable
304 AMD 760
305         Buz perfect-tolerable
306 --
307 In general, people on the user mailinglist won't give you much of a chance
308 if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
309 rather want to spend some more money on better boards. In general, VIA
310 mainboard's IDE/PCI performance will also suck badly compared to others.
311 You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
312 Basically, you can assume that if the Buz works, the LML33 will work too. If
313 the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
314 different mainboard chipsets from all of the supported cards.
315
316 If you experience timeouts during capture, buy a better mainboard or lower
317 the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
318 output size etc.'). If it hangs, there's little we can do as of now. Check
319 your IRQs and make sure the card has its own interrupts.
320
321 ===========================
322
323 4. Programming interface
324
325 This driver conforms to video4linux2. Support for V4L1 and for the custom
326 zoran ioctls has been removed in kernel 2.6.38.
327
328 For programming example, please, look at lavrec.c and lavplay.c code in
329 the MJPEG-tools (http://mjpeg.sf.net/).
330
331 Additional notes for software developers:
332
333    The driver returns maxwidth and maxheight parameters according to
334    the current TV standard (norm). Therefore, the software which
335    communicates with the driver and "asks" for these parameters should
336    first set the correct norm. Well, it seems logically correct: TV
337    standard is "more constant" for current country than geometry
338    settings of a variety of TV capture cards which may work in ITU or
339    square pixel format.
340
341 ===========================
342
343 5. Applications
344
345 Applications known to work with this driver:
346
347 TV viewing:
348 * xawtv
349 * kwintv
350 * probably any TV application that supports video4linux or video4linux2.
351
352 MJPEG capture/playback:
353 * mjpegtools/lavtools (or Linux Video Studio)
354 * gstreamer
355 * mplayer
356
357 General raw capture:
358 * xawtv
359 * gstreamer
360 * probably any application that supports video4linux or video4linux2
361
362 Video editing:
363 * Cinelerra
364 * MainActor
365 * mjpegtools (or Linux Video Studio)
366
367 ===========================
368
369 6. Concerning buffer sizes, quality, output size etc.
370
371 The zr36060 can do 1:2 JPEG compression. This is really the theoretical
372 maximum that the chipset can reach. The driver can, however, limit compression
373 to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
374 can't handle 1:2 compression without stopping capture after only a few minutes.
375 With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
376 1:4 max. compression mode.
377
378 100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
379 (size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
380 fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
381 414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
382 (quantization) tables, and you'll get to something like 512kB per frame for
383 1:2 compression. For 1:4 compression, you'd have frames of half this size.
384
385 Some additional explanation by Martin Samuelsson, which also explains the
386 importance of buffer sizes:
387 --
388 > Hmm, I do not think it is really that way. With the current (downloaded
389 > at 18:00 Monday) driver I get that output sizes for 10 sec:
390 > -q 50 -b 128 : 24.283.332 Bytes
391 > -q 50 -b 256 : 48.442.368
392 > -q 25 -b 128 : 24.655.992
393 > -q 25 -b 256 : 25.859.820
394
395 I woke up, and can't go to sleep again. I'll kill some time explaining why
396 this doesn't look strange to me.
397
398 Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
399 actually use that number or not, but that's not too important right now.
400
401 704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
402 3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
403 1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
404 output becomes 512 bits per block. Actually 510, but 512 is simpler to use
405 for calculations.
406
407 Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
408 becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
409 here, so we don't need to do any fancy corrections for bits-per-pixel or such
410 things. 101376 bytes per field.
411
412 d1 video contains two fields per frame. Those sum up to 202752 bytes per
413 frame, and one of those frames goes into each buffer.
414
415 But wait a second! -b128 gives 128kB buffers! It's not possible to cram
416 202752 bytes of JPEG data into 128kB!
417
418 This is what the driver notice and automatically compensate for in your
419 examples. Let's do some math using this information:
420
421 128kB is 131072 bytes. In this buffer, we want to store two fields, which
422 leaves 65536 bytes for each field. Using 3168 blocks per field, we get
423 20.68686868... available bytes per block; 165 bits. We can't allow the
424 request for 256 bits per block when there's only 165 bits available! The -q50
425 option is silently overridden, and the -b128 option takes precedence, leaving
426 us with the equivalence of -q32.
427
428 This gives us a data rate of 165 bits per block, which, times 3168, sums up
429 to 65340 bytes per field, out of the allowed 65536. The current driver has
430 another level of rate limiting; it won't accept -q values that fill more than
431 6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
432 a safe bet. Personally, I think I would have lowered requested-bits-per-block
433 by one, or something like that.) We can't use 165 bits per block, but have to
434 lower it again, to 6/8 of the available buffer space: We end up with 124 bits
435 per block, the equivalence of -q24. With 128kB buffers, you can't use greater
436 than -q24 at -d1. (And PAL, and 704 pixels width...)
437
438 The third example is limited to -q24 through the same process. The second
439 example, using very similar calculations, is limited to -q48. The only
440 example that actually grab at the specified -q value is the last one, which
441 is clearly visible, looking at the file size.
442 --
443
444 Conclusion: the quality of the resulting movie depends on buffer size, quality,
445 whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
446 module to do 1:4 instead of 1:2 compression, etc.
447
448 If you experience timeouts, lowering the quality/buffersize or using
449 'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
450 proven by the Buz.
451
452 ===========================
453
454 7. It hangs/crashes/fails/whatevers! Help!
455
456 Make sure that the card has its own interrupts (see /proc/interrupts), check
457 the output of dmesg at high verbosity (load zr36067.o with debug=2,
458 load all other modules with debug=1). Check that your mainboard is favorable
459 (see question 2) and if not, test the card in another computer. Also see the
460 notes given in question 3 and try lowering quality/buffersize/capturesize
461 if recording fails after a period of time.
462
463 If all this doesn't help, give a clear description of the problem including
464 detailed hardware information (memory+brand, mainboard+chipset+brand, which
465 MJPEG card, processor, other PCI cards that might be of interest), give the
466 system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
467 the kernel version, driver version, glibc version, gcc version and any other
468 information that might possibly be of interest. Also provide the dmesg output
469 at high verbosity. See 'Contacting' on how to contact the developers.
470
471 ===========================
472
473 8. Maintainers/Contacting
474
475 The driver is currently maintained by Laurent Pinchart and Ronald Bultje
476 (<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug
477 reports or questions, please contact the mailinglist instead of the developers
478 individually. For user questions (i.e. bug reports or how-to questions), send
479 an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to
480 help programming), send an email to <mjpeg-developer@lists.sf.net>. See
481 http://www.sf.net/projects/mjpeg/ for subscription information.
482
483 For bug reports, be sure to include all the information as described in
484 the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure
485 you're using the latest version (http://mjpeg.sf.net/driver-zoran/).
486
487 Previous maintainers/developers of this driver include Serguei Miridonov
488 <mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks
489 <dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>.
490
491 ===========================
492
493 9. License
494
495 This driver is distributed under the terms of the General Public License.
496
497     This program is free software; you can redistribute it and/or modify
498     it under the terms of the GNU General Public License as published by
499     the Free Software Foundation; either version 2 of the License, or
500     (at your option) any later version.
501
502     This program is distributed in the hope that it will be useful,
503     but WITHOUT ANY WARRANTY; without even the implied warranty of
504     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
505     GNU General Public License for more details.
506
507     You should have received a copy of the GNU General Public License
508     along with this program; if not, write to the Free Software
509     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
510
511 See http://www.gnu.org/ for more information.