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