The Zoran driver

통합 Zoran driver와 FAQ

이 `GPL-2.0` 문서는 `zr360x7`, `zoran`, Buz, DC10·DC10+, DC30·DC30+, LML33 계열을 하나로 지원하는 통합 Zoran driver의 FAQ입니다.

원문 project website는 `http://mjpeg.sourceforge.net/driver-zoran/`입니다. 이어지는 절은 지원 card, TV decoder·encoder capability, module loading, mainboard 호환성, programming interface, application, JPEG buffer 계산과 문제 보고 절차를 설명합니다.

.. SPDX-License-Identifier: GPL-2.0

The Zoran driver
================

unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)

website: http://mjpeg.sourceforge.net/driver-zoran/


Frequently Asked Questions
--------------------------

지원 card와 chip 구성

지원 대상은 Iomega Buz, Linux Media Labs `LML33`·`LML33R10`, Pinnacle/Miro `DC10`·`DC10+`·`DC30`·`DC30+`와 여러 이름으로 판매된 관련 board입니다.

Iomega Buz는 `zr36067` PCI controller, `zr36060` MJPEG codec, `saa7111` TV decoder, `saa7185` TV encoder를 사용합니다. Composite와 S-video 입출력, PAL·SECAM 720x576 25 fps와 NTSC 720x480 29.97 fps를 지원하며 card number는 `7`입니다.

AverMedia 6 Eyes `AVS6EYES`는 `zr36067`, `zr36060`, `ks0127`, `bt866` 조합입니다. Physical input 6개 중 1-6은 composite, 1-2·3-4·5-6 쌍은 S-video, 1-3은 component로도 동작하며 composite output 하나가 있습니다. Norm과 frame size는 Buz와 같고 card number는 `8`입니다. 자동 검출되지 않으므로 `card=8`이 필요합니다.

`LML33`은 `zr36067`, `zr36060`, `bt819`, `bt856` 조합이고 card number `5`입니다. `LML33R10`은 `zr36067`, `zr36060`, `saa7114`, `adv7170` 조합이고 card number `6`입니다. 둘 다 composite와 S-video를 제공하며 PAL 720x576 25 fps와 NTSC 720x480 29.97 fps를 지원합니다.

Pinnacle/Miro `DC10(new)`은 `zr36057`, `zr36060`, `saa7110a`, `adv7176` 조합이고 card number `1`입니다. `DC10+`는 PCI controller가 `zr36067`인 같은 계열이며 card number `2`입니다. 두 card 모두 composite, S-video, internal 입출력을 제공하고 PAL·SECAM 768x576 25 fps와 NTSC 640x480 29.97 fps를 지원합니다.

`DC10(old)`은 `zr36057`, `zr36050`, `zr36016` 또는 Fuji `md0211` Video Front End, `vpx3220a`, `mse3000` 또는 `adv7176` 조합이고 card number `0`입니다. 입출력과 norm·geometry는 새 DC10 계열과 같습니다.

`DC30`은 `zr36057`, `zr36050`, `zr36016`, `vpx3225d/vpx3220a/vpx3216b`, `adv7176` 조합이고 card number `3`입니다. `DC30+`는 controller가 `zr36067`인 유사 조합이며 card number `4`입니다. 원문 driver 목록의 `zr36015` 표기를 포함해 각 module 이름은 source block에서 보존합니다.

각 board는 공통으로 `videodev`, `i2c-core`, `i2c-algo-bit`, `videocodec`와 board별 decoder·encoder·codec module을 사용합니다. 현재 `mse3000`과 `vpx3224` module은 제공되지 않는다고 문서가 명시합니다.

What cards are supported
------------------------

Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
DC10/DC10+/DC30/DC30+ and related boards (available under various names).

Iomega Buz
~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7111 TV decoder
* Philips saa7185 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7111, saa7185, zr36060, zr36067

Inputs/outputs: Composite and S-video

Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)

Card number: 7

AverMedia 6 Eyes AVS6EYES
~~~~~~~~~~~~~~~~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Samsung ks0127 TV decoder
* Conexant bt866  TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, ks0127, bt866, zr36060, zr36067

Inputs/outputs:
        Six physical inputs. 1-6 are composite,
        1-2, 3-4, 5-6 doubles as S-video,
        1-3 triples as component.
        One composite output.

Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)

Card number: 8

.. note::

   Not autodetected, card=8 is necessary.

Linux Media Labs LML33
~~~~~~~~~~~~~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Brooktree bt819 TV decoder
* Brooktree bt856 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, bt819, bt856, zr36060, zr36067

Inputs/outputs: Composite and S-video

Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)

Card number: 5

Linux Media Labs LML33R10
~~~~~~~~~~~~~~~~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7114 TV decoder
* Analog Devices adv7170 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7114, adv7170, zr36060, zr36067

Inputs/outputs: Composite and S-video

Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)

Card number: 6

Pinnacle/Miro DC10(new)
~~~~~~~~~~~~~~~~~~~~~~~

* Zoran zr36057 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067

Inputs/outputs: Composite, S-video and Internal

Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)

Card number: 1

Pinnacle/Miro DC10+
~~~~~~~~~~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36060 MJPEG codec
* Philips saa7110a TV decoder
* Analog Devices adv7176 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, saa7110, adv7175, zr36060, zr36067

Inputs/outputs: Composite, S-video and Internal

Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)

Card number: 2

Pinnacle/Miro DC10(old)
~~~~~~~~~~~~~~~~~~~~~~~

* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
* Micronas vpx3220a TV decoder
* mse3000 TV encoder or Analog Devices adv7176 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067

Inputs/outputs: Composite, S-video and Internal

Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)

Card number: 0

Pinnacle/Miro DC30
~~~~~~~~~~~~~~~~~~

* Zoran zr36057 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067

Inputs/outputs: Composite, S-video and Internal

Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)

Card number: 3

Pinnacle/Miro DC30+
~~~~~~~~~~~~~~~~~~~

* Zoran zr36067 PCI controller
* Zoran zr36050 MJPEG codec
* Zoran zr36016 Video Front End
* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
* Analog Devices adv7176 TV encoder

Drivers to use: videodev, i2c-core, i2c-algo-bit,
videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067

Inputs/outputs: Composite, S-video and Internal

Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)

Card number: 4

.. note::

   #) No module for the mse3000 is available yet
   #) No module for the vpx3224 is available yet

TV broadcast format과 decoder capability

NTSC·PAL·SECAM이라는 color system 이름만으로 frame을 decode하기에는 정보가 부족합니다. 각 TV standard에는 여러 broadcast format이 있고 모든 decoder나 driver 조합이 이를 전부 처리하지는 못합니다. 문서는 전 세계에 11개 TV broadcast format이 있다고 설명합니다.

CCIR은 signal broadcast에 필요한 parameter를 A, B, D, E, F, G, H, I, K, K1, L, M, N 등의 standard로 정의하지만 color system 자체는 거의 규정하지 않습니다. A·E·F는 더 이상 사용되지 않습니다.

일반적으로 NTSC는 미국·일본·멕시코·캐나다 등에서 쓰는 CCIR-M과 NTSC color system을, PAL은 여러 국가의 CCIR-B/G와 PAL을, SECAM은 프랑스 등의 CCIR-L과 SECAM을 가리킵니다.

SECAM의 다른 변형인 CCIR-D/K는 Bulgaria, China, Slovakia, Hungary, Republic of Korea, Poland, Romania 등에서 사용됩니다. CCIR-H는 PAL 또는 때때로 SECAM을 쓰며 Egypt, Libya, Sri Lanka, Syrian Arab Republic에서 사용됩니다. CCIR-I의 PAL은 Great Britain, Hong Kong, Ireland, Nigeria, South Africa에서 사용됩니다.

CCIR-N은 PAL color system·frame size와 NTSC frame rate를 결합하며 Argentina, Uruguay 등에서 사용됩니다. 이 설명은 audio broadcast 방식은 다루지 않습니다. 원문은 Sony 지원 site와 방송 norm 참고 URL 두 곳을 추가로 제공합니다.

`NTSC 4.43`은 주로 NTSC playback이 가능한 PAL VCR에서 쓰는 수정 NTSC이고, `PAL 60`과 `NTSC 44`도 같은 계열로 보입니다. `NTSC Comb`은 delay line 대신 comb filter로 chroma와 luma를 분리하는 decoder mode로 추정되지만 저자는 확정하지 못했습니다.

1.1 What the TV decoder can do an what not
------------------------------------------

The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
information is not enough. There are several formats of the TV standards.
And not every TV decoder is able to handle every format. Also the every
combination is supported by the driver. There are currently 11 different
tv broadcast formats all aver the world.

The CCIR defines parameters needed for broadcasting the signal.
The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
The CCIR says not much about the colorsystem used !!!
And talking about a colorsystem says not to much about how it is broadcast.

The CCIR standards A,E,F are not used any more.

When you speak about NTSC, you usually mean the standard: CCIR - M using
the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
and a few others.

When you talk about PAL, you usually mean: CCIR - B/G using the PAL
colorsystem which is used in many Countries.

When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
which is used in France, and a few others.

There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.

The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
Egypt, Libya, Sri Lanka, Syrain Arab. Rep.

The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.

The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
and is used in Argentina, Uruguay, an a few others

We do not talk about how the audio is broadcast !

A rather good sites about the TV standards are:
http://www.sony.jp/support/
http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
and http://www.cabl.com/restaurant/channel.html

Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
be the same as NTSC 4.43.
NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
to split coma and luma instead of a Delay line.

But I did not defiantly find out what NTSC Comb is.

Philips saa7111 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1997, is used in the BUZ and
- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM

Philips saa7110a TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
- can handle: PAL B/G, NTSC M and SECAM

Philips saa7114 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 2000, is used in the LML33R10 and
- can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM

Brooktree bt819 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1996, and is used in the LML33 and
- can handle: PAL B/D/G/H/I, NTSC M

Micronas vpx3220a TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1996, is used in the DC30 and DC30+ and
- can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb

Samsung ks0127 TV decoder
~~~~~~~~~~~~~~~~~~~~~~~~~

- is used in the AVS6EYES card and
- can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM

TV encoder capability

TV encoder는 decoder와 반대 방향으로 동작합니다. Digital data를 받아 composite 또는 SVHS signal을 생성하며 color system과 TV norm의 배경은 앞 decoder 절과 같습니다.

`adv717x`는 PAL N을 생성할 수 있어야 하지만 register에는 PAL N 전용 설정이 없습니다. 문서는 다른 standard의 설정을 재사용해야 할 수 있으며 PAL M 설정이 동작할 가능성을 제시합니다.

What the TV encoder can do an what not
--------------------------------------

The TV encoder is doing the "same" as the decoder, but in the other direction.
You feed them digital data and the generate a Composite or SVHS signal.
For information about the colorsystems and TV norm take a look in the
TV decoder section.

Philips saa7185 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1996, is used in the BUZ
- can generate: PAL B/G, NTSC M

Brooktree bt856 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1994, is used in the LML33
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)

Analog Devices adv7170 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 2000, is used in the LML300R10
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60

Analog Devices adv7175 TV Encoder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
- can generate: PAL B/D/G/H/I/N, PAL M, NTSC M

ITT mse3000 TV encoder
~~~~~~~~~~~~~~~~~~~~~~

- was introduced in 1991, is used in the DC10 old
- can generate: PAL , NTSC , SECAM

Conexant bt866 TV encoder
~~~~~~~~~~~~~~~~~~~~~~~~~

- is used in AVS6EYES, and
- can generate: NTSC/PAL, PAL-M, PAL-N

The adv717x, should be able to produce PAL N. But you find nothing PAL N
specific in the registers. Seem that you have to reuse a other standard
to generate PAL N, maybe it would work if you use the PAL M settings.

Module loading과 mainboard 호환성

먼저 `zr36067.o`를 load합니다. Card를 자동 검출하지 못하면 앞 절의 card number를 `card=X` insmod option으로 지정합니다. 여러 card는 `card=X1[,X2[,X3,[X4[..]]]]` 형식으로 지정합니다.

자동화를 위해 `/etc/modprobe.d/zoran.conf`에 `options zr36067 card=...`와 `alias char-major-81-0 zr36067`을 추가할 수 있습니다. 다만 alias는 module을 즉시 load하지 않고 요청 시 loading만 자동화합니다.

일부 system에서 일반 user가 `xawtv`를 시작하면 module loading 권한이 없어 `permission denied`가 날 수 있습니다. X를 기본 사용하면 `XF86Config-4`에 `Load "v4l"`을 추가하고, X를 쓰지 않으면 startup script인 보통 `rc.local`에서 `v4l-conf -c <device>`를 실행해 root account로 boot 때 module을 준비할 수 있습니다.

문서에 기록된 당시 경험은 SiS·Intel chipset을 상대적으로 양호하게, VIA를 문제 가능성이 높은 것으로 평가합니다. Buz는 평균적으로 DC10+·LML33보다 문제가 많았고 VIA MVP3·KT 계열에서 특히 좋지 않았습니다. 이 평가는 오래된 hardware 경험 기록이라는 맥락으로 읽어야 합니다.

두 Intel 440BX board는 dual CPU version이었습니다. 이후 Bernhard Praschinger는 AMD 751과 AMD 760에서 Buz가 perfect에서 tolerable 수준이었다고 덧붙였습니다.

대체로 Buz가 동작하면 LML33도 동작하고, LML33이 동작하면 DC10+·DC30+도 동작할 것으로 볼 수 있습니다. DC10+·DC30+가 지원 card 가운데 mainboard chipset 변화에 가장 관대하다고 문서는 설명합니다.

Capture timeout이 발생하면 mainboard를 바꾸거나 quality·buffer size를 낮춰 봅니다. Hang이 나면 IRQ를 확인하고 card가 단독 interrupt를 갖는지 확인해야 합니다.

How do I get this damn thing to work
------------------------------------

Load zr36067.o. If it can't autodetect your card, use the card=X insmod
option with X being the card number as given in the previous section.
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]

To automate this, add the following to your /etc/modprobe.d/zoran.conf:

options zr36067 card=X1[,X2[,X3[,X4[..]]]]
alias char-major-81-0 zr36067

One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
just automates loading. If you start using xawtv, the device won't load on
some systems, since you're trying to load modules as a user, which is not
allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
one of your startup scripts (normally rc.local) if you don't use X. Both
make sure that the modules are loaded on startup, under the root account.

What mainboard should I use (or why doesn't my card work)
---------------------------------------------------------


<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.

Experience tells us that people with a Buz, on average, have more problems
than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
based on a different chipset. Here's some notes from Andrew Stevens:

Here's my experience of using LML33 and Buz on various motherboards:

- VIA MVP3
        - Forget it. Pointless. Doesn't work.
- Intel 430FX (Pentium 200)
        - LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
- Intel 440BX (early stepping)
        - LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
- Intel 440BX (late stepping)
        - Buz tolerable, LML3 almost perfect (occasional single frame drops)
- SiS735
        - LML33 perfect, Buz tolerable.
- VIA KT133(*)
        - LML33 starting to get annoying, Buz poor enough that I have up.

- Both 440BX boards were dual CPU versions.

Bernhard Praschinger later added:

- AMD 751
        - Buz perfect-tolerable
- AMD 760
        - Buz perfect-tolerable

In general, people on the user mailinglist won't give you much of a chance
if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
rather want to spend some more money on better boards. In general, VIA
mainboard's IDE/PCI performance will also suck badly compared to others.
You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
Basically, you can assume that if the Buz works, the LML33 will work too. If
the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
different mainboard chipsets from all of the supported cards.

If you experience timeouts during capture, buy a better mainboard or lower
the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
output size etc.'). If it hangs, there's little we can do as of now. Check
your IRQs and make sure the card has its own interrupts.

Programming interface와 application

Driver는 Video4Linux2를 따릅니다. V4L1 support와 Zoran custom ioctl은 kernel 2.6.38에서 제거됐습니다. Programming example은 MJPEG-tools의 `lavrec.c`, `lavplay.c`와 `http://mjpeg.sf.net/`에서 확인할 수 있습니다.

Driver는 현재 TV standard인 norm에 따라 `maxwidth`와 `maxheight`를 반환합니다. Application은 이 값을 질의하기 전에 올바른 norm을 먼저 설정해야 합니다. 한 국가의 TV standard가 capture card마다 달라질 수 있는 ITU 또는 square-pixel geometry보다 더 고정적이라는 설계입니다.

TV viewing에는 `xawtv`, `kwintv`와 V4L/V4L2 application이 알려져 있습니다. MJPEG capture·playback에는 `mjpegtools/lavtools` 또는 Linux Video Studio, `gstreamer`, `mplayer`를 사용할 수 있습니다.

General raw capture에는 `xawtv`, `gstreamer`와 일반 V4L/V4L2 application을, video editing에는 `Cinelerra`, `MainActor`, `mjpegtools` 또는 Linux Video Studio를 사용할 수 있습니다.

Programming interface
---------------------

This driver conforms to video4linux2. Support for V4L1 and for the custom
zoran ioctls has been removed in kernel 2.6.38.

For programming example, please, look at lavrec.c and lavplay.c code in
the MJPEG-tools (http://mjpeg.sf.net/).

Additional notes for software developers:

   The driver returns maxwidth and maxheight parameters according to
   the current TV standard (norm). Therefore, the software which
   communicates with the driver and "asks" for these parameters should
   first set the correct norm. Well, it seems logically correct: TV
   standard is "more constant" for current country than geometry
   settings of a variety of TV capture cards which may work in ITU or
   square pixel format.

Applications
------------

Applications known to work with this driver:

TV viewing:

* xawtv
* kwintv
* probably any TV application that supports video4linux or video4linux2.

MJPEG capture/playback:

* mjpegtools/lavtools (or Linux Video Studio)
* gstreamer
* mplayer

General raw capture:

* xawtv
* gstreamer
* probably any application that supports video4linux or video4linux2

Video editing:

* Cinelerra
* MainActor
* mjpegtools (or Linux Video Studio)

JPEG compression, buffer와 quality 계산

`zr36060`의 이론상 최대 JPEG compression은 1:2입니다. Driver는 maximum output size를 1:4 compression으로 제한할 수도 있습니다. Buz 같은 일부 card는 1:2에서 몇 분 뒤 capture가 멈출 수 있으므로 `low_bitrate=1`을 사용하면 최대 1:4 mode로 동작합니다.

실질적으로 JPEG quality 100%가 1:2 compression입니다. Full PAL 720x576에서 JPEG field는 YUY2이므로 field당 `720x288x16/2 bits = 207360 bytes`, frame당 두 field로 `414720 bytes`입니다. Header와 DHT Huffman·DQT quantization table을 더하면 1:2에서 frame당 약 512 kB이고, 1:4에서는 절반 정도입니다.

Martin Samuelsson의 10초 output 예는 `-q 50 -b 128`에서 24,283,332 byte, `-q 50 -b 256`에서 48,442,368 byte, `-q 25 -b 128`에서 24,655,992 byte, `-q 25 -b 256`에서 25,859,820 byte를 기록했습니다.

704x288 한 field는 202,752 pixel입니다. Block당 64 pixel로 나누면 field당 3,168 block이고 pixel당 2 byte이므로 block당 128 byte 또는 1,024 bit입니다. Quality 100%의 1:2 compression은 계산상 block당 512 bit를 허용합니다.

`d1q50`은 block당 256 bit를 원하므로 3,168 block에 811,008 bit, field당 101,376 byte입니다. Frame은 field 두 개이므로 202,752 byte가 필요하고 frame 하나가 buffer 하나에 들어갑니다.

그러나 `-b128`은 128 kB, 즉 131,072 byte뿐입니다. 두 field에 나누면 field당 65,536 byte이고 block당 약 20.686 byte 또는 165 bit만 쓸 수 있습니다. 따라서 block당 256 bit 요청을 수용할 수 없어 `-q50`이 조용히 override되고 `-b128`이 우선해 대략 `-q32`가 됩니다.

Driver에는 지정 buffer의 6/8보다 많이 채우는 `-q`를 허용하지 않는 추가 rate limit이 있습니다. 165 bit의 6/8인 약 124 bit/block까지 다시 낮아져 `-q24`와 같아집니다. PAL 704-pixel width의 `-d1`에서 128 kB buffer로는 `-q24`보다 크게 사용할 수 없습니다.

같은 과정으로 세 번째 예도 `-q24`, 두 번째 예는 `-q48`로 제한됩니다. 지정한 `-q`를 실제로 사용하는 것은 마지막 예이며 file size에서 차이가 드러납니다.

결론적으로 결과 movie quality는 buffer size, quality와 `zr36060` module의 `low_bitrate=1` 사용 여부 등에 좌우됩니다. Timeout이 있으면 quality·buffer size를 낮추거나 `low_bitrate=1`로 1:4 compression을 쓰는 것이 도움이 될 수 있습니다.

Concerning buffer sizes, quality, output size etc.
--------------------------------------------------


The zr36060 can do 1:2 JPEG compression. This is really the theoretical
maximum that the chipset can reach. The driver can, however, limit compression
to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
can't handle 1:2 compression without stopping capture after only a few minutes.
With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
1:4 max. compression mode.

100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
(quantization) tables, and you'll get to something like 512kB per frame for
1:2 compression. For 1:4 compression, you'd have frames of half this size.

Some additional explanation by Martin Samuelsson, which also explains the
importance of buffer sizes:
--
> Hmm, I do not think it is really that way. With the current (downloaded
> at 18:00 Monday) driver I get that output sizes for 10 sec:
> -q 50 -b 128 : 24.283.332 Bytes
> -q 50 -b 256 : 48.442.368
> -q 25 -b 128 : 24.655.992
> -q 25 -b 256 : 25.859.820

I woke up, and can't go to sleep again. I'll kill some time explaining why
this doesn't look strange to me.

Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
actually use that number or not, but that's not too important right now.

704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
output becomes 512 bits per block. Actually 510, but 512 is simpler to use
for calculations.

Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
here, so we don't need to do any fancy corrections for bits-per-pixel or such
things. 101376 bytes per field.

d1 video contains two fields per frame. Those sum up to 202752 bytes per
frame, and one of those frames goes into each buffer.

But wait a second! -b128 gives 128kB buffers! It's not possible to cram
202752 bytes of JPEG data into 128kB!

This is what the driver notice and automatically compensate for in your
examples. Let's do some math using this information:

128kB is 131072 bytes. In this buffer, we want to store two fields, which
leaves 65536 bytes for each field. Using 3168 blocks per field, we get
20.68686868... available bytes per block; 165 bits. We can't allow the
request for 256 bits per block when there's only 165 bits available! The -q50
option is silently overridden, and the -b128 option takes precedence, leaving
us with the equivalence of -q32.

This gives us a data rate of 165 bits per block, which, times 3168, sums up
to 65340 bytes per field, out of the allowed 65536. The current driver has
another level of rate limiting; it won't accept -q values that fill more than
6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
a safe bet. Personally, I think I would have lowered requested-bits-per-block
by one, or something like that.) We can't use 165 bits per block, but have to
lower it again, to 6/8 of the available buffer space: We end up with 124 bits
per block, the equivalence of -q24. With 128kB buffers, you can't use greater
than -q24 at -d1. (And PAL, and 704 pixels width...)

The third example is limited to -q24 through the same process. The second
example, using very similar calculations, is limited to -q48. The only
example that actually grab at the specified -q value is the last one, which
is clearly visible, looking at the file size.
--

Conclusion: the quality of the resulting movie depends on buffer size, quality,
whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
module to do 1:4 instead of 1:2 compression, etc.

If you experience timeouts, lowering the quality/buffersize or using
'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
proven by the Buz.

Hang·crash·capture 실패 진단

먼저 `/proc/interrupts`에서 card가 단독 interrupt를 갖는지 확인합니다. `zr36067.o`는 `debug=2`, 다른 module은 `debug=1`로 load해 높은 verbosity의 `dmesg`를 확인합니다.

Mainboard가 앞 호환성 경험에 비추어 적합한지 확인하고 필요하면 다른 computer에서 card를 시험합니다. 일정 시간 뒤 recording이 실패하면 quality, buffer size, capture size를 낮춰 봅니다.

그래도 해결되지 않으면 문제를 명확히 설명하고 memory 용량·brand, mainboard·chipset·brand, MJPEG card, processor, 관련 PCI card 등 상세 hardware 정보를 제공합니다. `/proc/interrupts`, `/proc/dma`, `/proc/devices`의 system PnP 정보도 포함합니다.

Kernel·driver·glibc·gcc version과 관련될 수 있는 기타 정보, 높은 verbosity의 `dmesg` output도 함께 제공합니다. 개발자 연락 방법은 뒤의 maintainer 절을 참고합니다.

It hangs/crashes/fails/whatevers! Help!
---------------------------------------

Make sure that the card has its own interrupts (see /proc/interrupts), check
the output of dmesg at high verbosity (load zr36067.o with debug=2,
load all other modules with debug=1). Check that your mainboard is favorable
(see question 2) and if not, test the card in another computer. Also see the
notes given in question 3 and try lowering quality/buffersize/capturesize
if recording fails after a period of time.

If all this doesn't help, give a clear description of the problem including
detailed hardware information (memory+brand, mainboard+chipset+brand, which
MJPEG card, processor, other PCI cards that might be of interest), give the
system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
the kernel version, driver version, glibc version, gcc version and any other
information that might possibly be of interest. Also provide the dmesg output
at high verbosity. See 'Contacting' on how to contact the developers.

이전 maintainer와 developer

문서가 기록한 이전 maintainer·developer는 Laurent Pinchart, Ronald Bultje, Serguei Miridonov, Wolfgang Scherr, Dave Perks, Rainer Johanni입니다.

Maintainers/Contacting
----------------------

Previous maintainers/developers of this driver are
- Laurent Pinchart <laurent.pinchart@skynet.be>
- Ronald Bultje rbultje@ronald.bitfreak.net
- Serguei Miridonov <mirsev@cicese.mx>
- Wolfgang Scherr <scherr@net4you.net>
- Dave Perks <dperks@ibm.net>
- Rainer Johanni <Rainer@Johanni.de>

Driver license

이 driver는 GNU General Public License 조건으로 배포됩니다. Free Software Foundation이 공표한 GPL version 2 또는 선택에 따라 그 이후 version의 조건으로 재배포하거나 수정할 수 있습니다.

Program은 유용하길 바라며 제공되지만 어떠한 보증도 없습니다. 상품성이나 특정 목적 적합성에 대한 묵시적 보증도 제공하지 않습니다. 자세한 내용은 GNU General Public License와 `http://www.gnu.org/`를 참고합니다.

Driver's License
----------------

    This driver is distributed under the terms of the General Public License.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

See http://www.gnu.org/ for more information.