[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectLinux driver for DC10plus video capture card. V 0.5test1
August 20, 2000.

Linux driver for Miro/Pinnacle Systems Inc. DC10plus and some DC10 cards.

Version 0.5test1:

Some minor changes are related to the workaround for older DC10 (non
plus) cards with ZR36057 chip. If you have such a card and previous
version failed, please, try this driver instead.

If you still have problems with lavrec AVI recording utility from
lavtools-1.2p2, try -b option with different buffer sizes (256, 128,
64, 32, 16 Kbytes) and see what will happen. Please, send me fragments
of your log file regarding DC10 driver messages along with your bug

This release also is a first step to integrate this driver into the
kernel source: some header files have been removed and files buz.c and
buz.h have been renamed as dc10.c and dc10.h.

General information:

Driver homepage:

This is a driver for DC10plus capture cards from Pinnacle Systems
Inc. It also works with many old Miro DC10 cards with SAA7110A TV
decoder and ADV7176 TV encoder (please, make sure that your card has
these chips, otherwise the driver will not work).

The driver is Video4Linux compliant and contains extensions to
provide hardware support for full motion MJPEG compression and
decompression. Since this driver is a derivative from the driver for
Buz Iomega cards written by Dr. Rainer Johanni, they both have compatible
API. I hope that this API will become a standard. At least, there is
another driver, for LML33 cards, which shares the same API:

Formats supported by DC10plus driver:

PAL/SECAM: up to 768x576 at 25 full frames per second;
NTSC: up to 640x480 at 30 full frames per second.

The JPEG compression ratio is adjustable, so the data rate can be
varied from 6-7 MBytes/s down to 1-2 MBytes/s depending on the
required image quality.

Hardware compression

Since the card provides hardware compression, even low end machines
can be successfully used for movie capture and playback. I've tested
the driver with 2.2.14 kernel running on 233 MHz Pentium MMX with 64M
RAM on 430TX motherboard and with 10GB IDE drive from Western Digital

On one test run I've got 0 frames dropped during about 20 minutes of
full motion NTSC (I live in Mexico) video capture with fully
synchronized audio. The command was

lavrec -fa -in -d1 -l -1 -q30 -w /dos/g/capture/Linux/test%03d.avi

for recording, and

lavplay -n128 /dos/g/capture/Linux/test*.avi

for playback. (See lavtools distribution for more information).

Typical run of similar test can provide as few as 6-8 dropped frames per
half of an hour. You mileage may vary, though.

Compilation and installation

Please, read file README regarding compilation and installation
issues. Note, that you will need mem=XXX setting in lilo.conf, or
bigphysarea patch only if you are planning to use uncompressed motion
or still capture using XawTV and other programs.

If you use only MJPEG compressed capture provided by the driver, you
should not need large memory areas for DMA. In this case, you will be
able to capture and playback movies with lavtools, however you will
not be able to use capture features of XawTV and other similar
programs (you can still watch video on the screen).

Tested applications:

XawTV to watch video on your computer monitor.

kwintv the same (you might need to use option lock_norm=1, see
the description in Changes section below).

lavtools To record and playback AVI or Quicktime files. Note: you
will need patched version, lavtools-1.2p2 to support new
features of this driver. Please visit driver homepage for
more info.

Broadcast2000 reportedly (I didn't try that) can accept movies
recorded by lavrec for editing and then edited movie
can be played back by lavplay program.

MainActor 3.53 also can accept movies recorded by lavrec for editing.

Changes in v0.4:

1. Now the driver (with new lavtools-1.2p2) is able to deal with cropped
TV clips produced by miro/Pinnacle software. Try new lavplay on clips
which you couldn't play before.

2. For software developers: now 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. Remember that users now you can lock the
norm (see item 3 below) to avoid any ambiguity.

3. Two new parameters have been added for the driver configuration on

lock_norm=1 will disable TV standard switching but will not
produce any error response to the application
trying to change norm.

lock_norm=2 will disable changing TV standard but it will
also return error to the application attempting
to switch norm. It can be useful with applications
like XawTV which switch norm at the beginning
to find out which TV standards are available.

This feature can be useful in combination with default_norm
parameter to lock the norm for current country and prevent
it from switching by some not well behaving programs. Default
is 0, i.e. switching is enabled, however I would recommend
to always lock the norm unless you are dealing with
different TV standards.

pass_through=0 will enable TV output only when the device is
in use by some program. Otherwise, the TV
monitor will show a standard color bar.

pass_through=1 will enable passing of input TV signal to the

Default is 0.

4. Interrupt processing code was modified to make the driver working
even after codec crash. It should greatly improve the driver
reliability. I've tested switching channels on the VCR which was
used as video signal source during recording with lavrec, and the
driver survived the switch and other glitches in the signal,
restarting and continuing capture. Some frames in the clip were
corrupted but they can be cut by video editing software. The driver
also survives corrupted frames during playback.

5. The driver now is able to play MJPEG files on the computer monitor
screen simultaneously with playing on the attached TV monitor. However,
there is only one utility which can provide such functionality:
mplay_screen from examples directory of buz-1.0.1 driver distribution.
It plays files in its own format which must be recorded by mrecord from
the same distribution. This is a proprietary format, incompatible with
AVI format. Nevertheless, now the driver is almost ready for
applications which will play AVI files on the computer screen.
Please, see item 7 below for other experimental feature.

6. SECAM support. The driver now provides partial support for SECAM TV
standard used in Russia and some other countries from former Soviet
Union. Probably, this standard is also used in France but I'm not
sure of this. The partial (not full) support means that the driver
can accept color SECAM signal for capture, so users from these
countries can record clips and watch video on the computer monitor
screen using XawTV or similar application in full color, but the
image on the attached TV monitor during the capture can be B&W or
with messed up colors. Note, however, that this will be only during
capture. The playback of the captured clip will be in PAL standard
and with full color! So, now users from Russia and other countries
with SECAM standard can watch TV programs and capture clips from
broadcast channels. Of course, since DC10plus does not have built-in
tuner, you will need to take the signal from your VCR, TV or other
source with external tuner.

7. Now the driver can be used by two programs at the same time
(please, see warning note below regarding this feature). Using XawTV
you can watch what you are recording or playing back with lavtools.
I've tested the following sequence and it worked for me:

* start xawtv and switch inputs, TV standards, and adjust video
(contrast, saturation, etc.). You may also run your favorite
audio mixer application to adjust audio inputs.

* run lavrec with options:

-i<set your input and norm here> (to choose proper input
and TV standard)

-l -1 (to use audio mixer settings)

Other lavrec option can be added at your choice.

* watch the movie in xawtv window while recording it as AVI or
Quicktime file.

* when recording is finished, run lavplay or xlav and watch your
clip in xawtv window.

* Note: you should not quit xawtv during recording or playing back.
If you quit xawtv during recording or playback, another lavtools
program will stop and may even crash.

I'm not sure that the same will work for you. You can try but,
please, be careful.

WARNING! This is an experimental feature and I'm not sure if it will
be supported in the future. The driver was not designed to be used
like this and it has no protection against any interference between

8. /proc/zoran0 entry: using 'cat /proc/zoran0' you can see the
contents of ZR36057/67 chip registers. It is also possible to modify
the contents of some registers directly. WARNING: modified contents
is not stored in the driver memory, if you restart any program which
uses this driver or even change position or cause redraw of a window
of xawtv or other program, the original registers contents will be
restored by the driver. However, it can be used to change ZR36067
registers on the fly for fine tuning and then to include these
changes into driver code. This feature is very limited and still
requires some documentation. However, if you are impatient, look at
buz_procfs.c code and (IMPORTANT!) read ZR36057/67 manual. To set
TopField bit, for example, you need to type as root:

echo TopField=1 > /proc/zoran0

If you use this feature and have found some interesting result, please, let
me know.

I've tested the driver with 2.2.14 and 2.2.16 kernel. There is still no
support for newer 2.4 kernels. However, it will come soon.

Please, try the driver, and let me know if something is wrong. It would
be nice if you fix something and send me a patch.

To download the driver and for other news and updates, please, visit

Good luck.

Serguei Miridonov

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.063 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site