LinuxTVWiki - User contributions [en]

TerraTec Cinergy T PCIe dual

2012-04-21T10:12:30Z

Liontooth:

A dual-tuner DVB-T PCIe card sold by TerraTec. This card appears to be supported from kernel 3.3 by LinuxTV drivers (not confirmed).

== Overview/Features ==

This is technically a very interesting card. The hardware is as follows:

* Tuner #1: microtune mt2063
* Demodulators #1: drx-3916k DVB-T/Analoge TV
* Tuner #2: microtune mt2063
* Demodulators #2: drx-3913k DVB-T/DVB-C
* PCI Express x1 Bridge: Conexant cx23885

== Support ==

This card is supported from kernel version 3.3 (?). The microtune tuner was merged in kernel version 3.3 (see [http://lwn.net/Articles/474793/ first submission]).

The card itself was added upstream on LinuxTV's git repository on [http://patchwork.linuxtv.org/patch/8879/ 2011-12-17] and may have been merged upstream.

The first frontend supports only DVB-T, but support for analogue TV is planned for kernel 3.4 or 3.5. The second frontend supports both DVB-T and DVB-C in a multifrontend device (spec's DVB v5 API).

Linux4Media cineS2 DVB-S2 Twin Tuner

2012-03-26T09:59:52Z

Liontooth: /* External Links */

A [[NGene_devices|nGene]] based [[DVB-S2]] [[DVB-S2 PCIe Cards|PCIe card]] from [[Linux4Media]]

[[Image:Media-Pointer_MP-S2_Front.jpg|right|thumb|200px|Linux4Media cineS2 DVB-S2 Twin Tuner ]]

==Overview/Features==
* Full Linux Support
* PCI-e x1
* Dual Tuner DVB-S/S2 card
* Ultra-Low Profile

===Components Used===
* [[NGene_devices|PCIe bridge MICRONAS APB 7202A B2]]
* [[STMicroelectronics_STV0900|Dual demodulator STM STV0900B]]
* [[ST_STV6110A|Tuner STM STV6110A]]
* [[Dual LNB STM LNBH24]]

===Other Images===
<gallery perrow=5>
Image:Media-Pointer_MP-S2_MICRONAS_APB_7202A_B2.jpg|PCIe bridge MICRONAS APB 7202A B2
Image:Media-Pointer_MP-S2_STV0900B.jpg|Dual demodulator STM STV0900B
Image:Media-Pointer_MP-S2_STV6110A.jpg|Tuner STM STV6110A
Image:Media-Pointer_MP-S2_LNBH24.jpg|Dual LNB STM LNBH24
</gallery>

===Identification===
$ lspci -vvvnn
02:00.0 Multimedia video controller [0400]: Micronas Semiconductor Holding AG Device [18c3:0720]
Subsystem: Micronas Semiconductor Holding AG Device <b>[18c3:abc3]</b>
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe8f0000 (32-bit, non-prefetchable) [size=64K]
Region 1: Memory at fe8e0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [58] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Device Serial Number 00-11-3c-20-07-00-00-00
Capabilities: [400] Virtual Channel <?>
Kernel driver in use: ngene
Kernel modules: ngene

or:
$ lspci -vvvnn
02:00.0 Multimedia video controller [0400]: Micronas Semiconductor Holding AG Device [18c3:0720]
Subsystem: Micronas Semiconductor Holding AG Device <b>[18c3:abc4]</b>
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe8f0000 (32-bit, non-prefetchable) [size=64K]
Region 1: Memory at fe8e0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [58] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Device Serial Number 00-11-3c-20-07-00-00-00
Capabilities: [400] Virtual Channel <?>
Kernel driver in use: ngene
Kernel modules: ngene

or:

03:00.0 Multimedia video controller [0400]: Micronas Semiconductor Holding AG Device [18c3:0720] (rev 01)
Subsystem: Micronas Semiconductor Holding AG Device '''[18c3:dd00]'''
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fddf0000 (32-bit, non-prefetchable) [size=64K]
Region 1: Memory at fdde0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [58] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [400] Virtual Channel <?>

==Making it Work==

Make sure that the external power supply is connected!!!

===Firmware===

$ wget http://www.digitaldevices.de/download/ngene_15.fw
$ cp ngene_15.fw /lib/firmware/

Device [18c3:dd00] needs Firmware >= 18
$ wget http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/ngene_18.fw
$ sudo cp ngene_18.fw /lib/firmware

===Driver===

$ hg clone http://linuxtv.org/hg/v4l-dvb/
$ cd v4l-dvb
$ make
$ make install

Also supported by the [[s2-liplianin]] v4l branch.

On RHEL / Centos / Scientific Linux 6.x the card works with video4linux driver RPM >= 20110208_132512-98.el6 from ATRPMS Repository.

==External Links==
[http://www.tecstore.net/Produkt/452055/CineS2-V6-DVB-S2-Twin-Tuner-%28Low-Profile%29-%28DVB-S2%29 CineS2 DVB-S2 Twin Tuner "Low Profile"]
[[Category:DVB-S2 PCIe Cards]]

Digital Devices DuoFlex C&T

2012-02-26T13:28:17Z

Liontooth: /* See also */

== Overview/Features ==
* PCI-e x1 (Bridge)
* Recieve Dual DVB-C/DVB-T in high definition simultaneously
* Independent descrambling of two transponders
* DVB-C HDTV H264 decoding
* DVB-T SD Mpeg2 decoding
* Mixed Mode feature (2x DVB-C / 2x DVB-T / DVB-C & DVB-T)

== Identification ==
PCI id:
Multimedia controller: Device dd01:0003

and an extra PCI Bridge:
PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)

==Making it work==
copied from VDR Portal (See Link below)

This uses Sources from:
http://linuxtv.org/hg/~endriss/ngene-octopus-test:
- ngene: cineS2(v3/v4/v5), SatixS2, PCIe-Bridge, mini PCIe-Bridge
- ddbridge: Octopus, Octopus LE, cineS2(v6)
- DuoFlex-S2, DuoFlex-CT, CI

and from
http://powarman.dyndns.org/hgwebdir.cgi/v4l-dvb-saa716x:
- TT S2-6400

Compilable with Kernel 2.6.35 and higher (2.6.30 and below doesn't work for sure).

How to Compile:

1. Download modified media_build:

<pre>hg clone http://linuxtv.org/hg/~endriss/media_build_experimental</pre>

2. Download Drivers and Compile:

<pre>cd media_build_experimental
make download
make untar</pre>

3. '''optional''': deselect unused modules:

<pre>make menuconfig</pre>

4. Build Drivers

<pre>make</pre>

5. install modules

<pre>make install
modprobe ddbridge
modprobe ngene</pre>

== Scanning for Channels ==

DVB-C:

<pre>w_scan -fc -c DE -t 3 -F > channels.dvb</pre>

DVB-T:

<pre>w_scan -ft -c DE -t 3 -F > channels.dvb</pre>

The C/T card has two frontends, frontend0 is QAM for DVB-C and frontend1 is OFDM for DVB-T.

== See also ==

* [http://linuxtv.org/hg/~endriss/ngene-octopus-test LinuxTV] - driver patches
* [https://launchpad.net/~yavdr/+archive/main Ubuntu PPA] (dkms package)
* [http://www.linux4media.de/files/DDTuner.zip DDTuner.zip] - System Driver
* [http://digital-devices.de/ Digital-Devices] - manufacturer website
* [http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/105803-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-sowie-tt-s2-6400/ VDR Portal] - Driver installation Howto

[[Category:DVB-C]]
[[Category:DVB-T]]
[[Category:PCIe]]

TerraTec Cinergy T PCIe dual

2012-02-25T22:12:40Z

Liontooth:

A dual-tuner DVB-T PCIe card sold by TerraTec. This card appears to be supported from kernel 3.3 by LinuxTV drivers (not confirmed).

== Overview/Features ==

This is technically a very interesting card. The hardware is as follows:

* Tuner #1: microtune mt2063
* Demodulators #1: drx-3916k DVB-T/Analoge TV
* Tuner #2: microtune mt2063
* Demodulators #2: drx-3913k DVB-T/DVB-C
* PCI Express x1 Bridge: Conexant cx23885

== Support ==

This card is supported from kernel version 3.3 (?). The microtune tuner was merged in kernel version 3.3 (see [http://lwn.net/Articles/474793/ first submission]).

The first frontend supports only DVB-T, but support for analogue TV is planned for kernel 3.4 or 3.5. The second frontend supports both DVB-T and DVB-C in a multifrontend device (spec's DVB v5 API).

NetUP Dual DVB T C CI RF

2012-02-25T22:00:37Z

Liontooth: /* Making it work */

NetUP Dual DVB-T/C-CI RF from [[NetUP Inc.]]

== Overview/Features ==
* PCI-e x1
* Supports two DVB-T/DVB-C transponders simultaneously
* Supports two analog audio/video channels simultaneously
* Independent descrambling of two transponders
* Hardware PID filtering

== Components Used ==
* Conexant CX23885
* STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver
* Xceive XC5000 silicon TV tuner
* Altera FPGA for Common Interafce

<gallery perrow=5>
Image:Netup_dual_dvb-c-t-fine.jpg|Front side of engineering prototype
</gallery>

== Identification ==
PCI id:
1B55:e2e4 NetUP Dual DVB-T/C-CI RF card

== Making it work ==

According to [http://www.netup.tv/en-EN/dual_dvb-t-c-ci_card.php NetUp's product page], the device works with their fork of Linux kernel 3.0.

The following instructions are outdated, using NetUp's fork of an earlier kernel.

Check out linux kernel (experimental):
<pre>
git clone http://udev.netup.ru/git/v4l-dvb.git linux-2.6.35-netup
cd linux-2.6.35-netup
make menuconfig
make && make modules_install && make install
</pre>

Change grub menu.lst config to boot new kernel (/boot/vmlinuz-2.6.35+).

Install firmware files into /lib/firmware folder:
<pre>
wget http://www.netup.tv/downloads/netup-dvb-t-c_firmware-v0.1.tbz2
tar xvfj netup-dvb-t-c_firmware-v0.1.tbz2
cp netup-dvb-t-c_firmware-v0.1/* /lib/firmware/
</pre>

== Tuning to DVB-C and DVB-T ==

Each port can be tuned to DVB-T or DVB-C using frontend0 or frontend1 accordingly.

For DVB-T use frontend0
<pre>
# tzap modul64
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/root/.tzap/channels.conf'
tuning to 578000000 Hz
video pid 0x0000, audio pid 0x0821
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
</pre>

For DVB-C use frontend1
<pre>
# czap -f 1 modul64
using '/dev/dvb/adapter0/frontend1' and '/dev/dvb/adapter0/demux0'
reading channels from file '/root/.czap/channels.conf'
2 modul64:578000000:INVERSION_AUTO:5900000:FEC_NONE:QAM_128:515:672:1509
2 modul64: f 578000000, s 5900000, i 2, fec 0, qam 4, v 0x203, a 0x2a0, s 0x5e5
status 10 | signal ffff | snr b851 | ber 00000000 | unc 0000000b | FE_HAS_LOCK
status 10 | signal ffff | snr ca3c | ber 00000000 | unc 0000000b | FE_HAS_LOCK
</pre>

== See also ==

* [http://www.netup.tv/en-EN/dual_dvb-t-c-ci_card.php NetUP Dual DVB-T/C-CI] - manufacturer website

[[Category:DVB-C]]
[[Category:PCIe]]

NetUP Dual DVB T C CI RF

2012-02-25T21:58:48Z

Liontooth: /* Making it work */

NetUP Dual DVB-T/C-CI RF from [[NetUP Inc.]]

== Overview/Features ==
* PCI-e x1
* Supports two DVB-T/DVB-C transponders simultaneously
* Supports two analog audio/video channels simultaneously
* Independent descrambling of two transponders
* Hardware PID filtering

== Components Used ==
* Conexant CX23885
* STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver
* Xceive XC5000 silicon TV tuner
* Altera FPGA for Common Interafce

<gallery perrow=5>
Image:Netup_dual_dvb-c-t-fine.jpg|Front side of engineering prototype
</gallery>

== Identification ==
PCI id:
1B55:e2e4 NetUP Dual DVB-T/C-CI RF card

== Making it work ==

According to [http://www.netup.tv/en-EN/dual_dvb-t-c-ci_card.php NetUp's product page], the device works with their fork of Linux kernel 3.0.

Check out linux kernel (experimental):
<pre>
git clone http://udev.netup.ru/git/v4l-dvb.git linux-2.6.35-netup
cd linux-2.6.35-netup
make menuconfig
make && make modules_install && make install
</pre>

Change grub menu.lst config to boot new kernel (/boot/vmlinuz-2.6.35+).

Install firmware files into /lib/firmware folder:
<pre>
wget http://www.netup.tv/downloads/netup-dvb-t-c_firmware-v0.1.tbz2
tar xvfj netup-dvb-t-c_firmware-v0.1.tbz2
cp netup-dvb-t-c_firmware-v0.1/* /lib/firmware/
</pre>

== Tuning to DVB-C and DVB-T ==

Each port can be tuned to DVB-T or DVB-C using frontend0 or frontend1 accordingly.

For DVB-T use frontend0
<pre>
# tzap modul64
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/root/.tzap/channels.conf'
tuning to 578000000 Hz
video pid 0x0000, audio pid 0x0821
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
status 10 | signal 0000 | snr 001b | ber bf8ec9c8 | unc 00000000 | FE_HAS_LOCK
</pre>

For DVB-C use frontend1
<pre>
# czap -f 1 modul64
using '/dev/dvb/adapter0/frontend1' and '/dev/dvb/adapter0/demux0'
reading channels from file '/root/.czap/channels.conf'
2 modul64:578000000:INVERSION_AUTO:5900000:FEC_NONE:QAM_128:515:672:1509
2 modul64: f 578000000, s 5900000, i 2, fec 0, qam 4, v 0x203, a 0x2a0, s 0x5e5
status 10 | signal ffff | snr b851 | ber 00000000 | unc 0000000b | FE_HAS_LOCK
status 10 | signal ffff | snr ca3c | ber 00000000 | unc 0000000b | FE_HAS_LOCK
</pre>

== See also ==

* [http://www.netup.tv/en-EN/dual_dvb-t-c-ci_card.php NetUP Dual DVB-T/C-CI] - manufacturer website

[[Category:DVB-C]]
[[Category:PCIe]]

TerraTec Cinergy T PCIe dual

2012-02-25T20:38:57Z

Liontooth: /* Support */

A dual-tuner DVB-T PCIe card sold by TerraTec. This card is not currently supported by LinuxTV drivers.
==Overview/Features==
This is technically a very interesting card. The hardware is as follows:

* Tuner #1: microtune mt2063
* Demodulators #1: drx-3916k DVB-T/Analoge TV
* Tuner #2: microtune mt2063
* Demodulators #2: drx-3913k DVB-T/DVB-C
* PCI Express x1 Bridge: Conexant cx23885
==Support==
This card is supported from kernel version 3.3. The microtune tuner was merged in kernel version 3.3.

The first frontend supports only DVB-T, but support for analogue TV is planned for kernel 3.4 or 3.5. The second frontend supports both DVB-T and DVB-C in a multifrontend device (spec's DVB v5 API).

DVB Conditional Access Modules

2012-02-25T19:55:20Z

Liontooth:

Any [[CAM]]s not listed on this page have not been tested, so may or may not work. If you try an unlisted one, please add it to this page in the appropriate section.

'''[[TechnoTrend]]/Hauppauge fullfeatured cards'''<br>
So far, all CAM modules are supported by these cards

'''[[TechnoTrend]]/Hauppauge budget-ci cards with v1.0A [[CI]] daughterboard'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Aston AstonCrypt
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04
* Aston Viaccess Dual or Professional [[CAM]]
* Aston AstonCrypt Professional [[CAM]]
* Aston Irdeto Professinal [[CAM]]
* Conax 4.00e (See also [[TechnoTrend TT-DVB-T 1500]])
* SCM (topuptv/uk)
* SCM Viaccess red label (for linux >= 2.6.14 or CVS dvb)
* Original TV Vlaanderen CAM (Mediaguard) with original Smartcard
* PowerCAM Pro v2.0.3 and v2.0.4
* oneCAM v1.0.0

''Incompatible [[CAM]]s:''
* ZetaCAM (Hardware: 2.01/Software: 2.26)
* SCM Viaccess red label (for linux < 2.6.14)

'''[[TechnoTrend]]/Hauppauge budget-ci cards with v1.1 CI daughterboard'''<br>
''Compatible [[CAM]]s:''
''Incompatible [[CAM]]s:''

'''KNC1/Terratec DVB-S/-T/-C budget cards'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Mascom Alphacrypt v1.0
* Mascom Cryptoworks
* Aston Viaccess Professional
* Aston AstonCrypt Professional
* Aston Irdeto Professional
* Aston Conax Professional
* SCM Viaccess (red label) (only 1 pid ?)
* Conax 4.00e
* SCM (topuptv/uk)

''Incompatible [[CAM]]s:''
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04

'''[[Hercules Smart TV Satellite]]''' ([[TwinHan|TwinHan clone]])<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label) (mostly working, random failures observed every few hours with french TPS)

''Incompatible [[CAM]]s:''
* Aston Viaccess

'''VisionPlus VisionDTV Sat-CI'''<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label)
* Aston 1.05 P/N 901274 Rev 1.2

''Incompatible [[CAM]]s'':
* Aston Viaccess Professional
* Aston Professional
* MatrixCAM Reloaded

==Also See==
* [[Conditional Access Module Usage Examples]]

[[Category:Development]]

DVB Conditional Access Modules

2012-02-25T19:54:48Z

Liontooth:

Any [[CAM]]s not listed on this page have not been tested, so may or may not work. If you try an unlisted one, please add it to this page in the appropriate section.

'''[[TechnoTrend]]/Hauppauge fullfeatured cards'''<br>
So far, all CAM modules are supported by these cards

'''[[TechnoTrend]]/Hauppauge budget-ci cards with v1.0A [[CI]] daughterboard'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Aston AstonCrypt
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04
* Aston Viaccess Dual or Professional [[CAM]]
* Aston AstonCrypt Professional [[CAM]]
* Aston Irdeto Professinal [[CAM]]
* Conax 4.00e (See also [[TechnoTrend TT-DVB-T 1500]])
* SCM (topuptv/uk)
* SCM Viaccess red label (for linux >= 2.6.14 or CVS dvb)
* Original TV Vlaanderen CAM (Mediaguard) with original Smartcard
* PowerCAM Pro v2.0.3 and v2.0.4
* oneCAM v1.0.0

''Incompatible [[CAM]]s:''
* ZetaCAM (Hardware: 2.01/Software: 2.26)
* SCM Viaccess red label (for linux < 2.6.14)

'''Technotrend/Hauppauge budget-ci cards with v1.1 CI daughterboard'''<br>
''Compatible [[CAM]]s:''
''Incompatible [[CAM]]s:''

'''KNC1/Terratec DVB-S/-T/-C budget cards'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Mascom Alphacrypt v1.0
* Mascom Cryptoworks
* Aston Viaccess Professional
* Aston AstonCrypt Professional
* Aston Irdeto Professional
* Aston Conax Professional
* SCM Viaccess (red label) (only 1 pid ?)
* Conax 4.00e
* SCM (topuptv/uk)

''Incompatible [[CAM]]s:''
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04

'''[[Hercules Smart TV Satellite]]''' ([[TwinHan|TwinHan clone]])<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label) (mostly working, random failures observed every few hours with french TPS)

''Incompatible [[CAM]]s:''
* Aston Viaccess

'''VisionPlus VisionDTV Sat-CI'''<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label)
* Aston 1.05 P/N 901274 Rev 1.2

''Incompatible [[CAM]]s'':
* Aston Viaccess Professional
* Aston Professional
* MatrixCAM Reloaded

==Also See==
* [[Conditional Access Module Usage Examples]]

[[Category:Development]]

DVB Conditional Access Modules

2012-02-25T19:54:21Z

Liontooth:

Any [[CAM]]s not listed on this page have not been tested, so may or may not work. If you try an unlisted one, please add it to this page in the appropriate section.

'''[[Technotrend]]/Hauppauge fullfeatured cards'''<br>
So far, all CAM modules are supported by these cards

'''[[Technotrend]]/Hauppauge budget-ci cards with v1.0A [[CI]] daughterboard'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Aston AstonCrypt
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04
* Aston Viaccess Dual or Professional [[CAM]]
* Aston AstonCrypt Professional [[CAM]]
* Aston Irdeto Professinal [[CAM]]
* Conax 4.00e (See also [[TechnoTrend TT-DVB-T 1500]])
* SCM (topuptv/uk)
* SCM Viaccess red label (for linux >= 2.6.14 or CVS dvb)
* Original TV Vlaanderen CAM (Mediaguard) with original Smartcard
* PowerCAM Pro v2.0.3 and v2.0.4
* oneCAM v1.0.0

''Incompatible [[CAM]]s:''
* ZetaCAM (Hardware: 2.01/Software: 2.26)
* SCM Viaccess red label (for linux < 2.6.14)

'''Technotrend/Hauppauge budget-ci cards with v1.1 CI daughterboard'''<br>
''Compatible [[CAM]]s:''
''Incompatible [[CAM]]s:''

'''KNC1/Terratec DVB-S/-T/-C budget cards'''<br>
''Compatible [[CAM]]s:''
* Philips Cryptoworks v1.0
* Mascom Alphacrypt v1.0
* Mascom Cryptoworks
* Aston Viaccess Professional
* Aston AstonCrypt Professional
* Aston Irdeto Professional
* Aston Conax Professional
* SCM Viaccess (red label) (only 1 pid ?)
* Conax 4.00e
* SCM (topuptv/uk)

''Incompatible [[CAM]]s:''
* MatrixCAM Reloaded
* Dream multimedia Magic Module v1.04

'''[[Hercules Smart TV Satellite]]''' ([[TwinHan|TwinHan clone]])<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label) (mostly working, random failures observed every few hours with french TPS)

''Incompatible [[CAM]]s:''
* Aston Viaccess

'''VisionPlus VisionDTV Sat-CI'''<br>
''Compatible [[CAM]]s'':
* SCM Viaccess (red label)
* Aston 1.05 P/N 901274 Rev 1.2

''Incompatible [[CAM]]s'':
* Aston Viaccess Professional
* Aston Professional
* MatrixCAM Reloaded

==Also See==
* [[Conditional Access Module Usage Examples]]

[[Category:Development]]

Hauppauge WinTV-HVR-4400

2012-02-11T13:12:07Z

Liontooth:

[[Image:HVR-4400-Front-LoRes.png|right|200px|Photo of front of card with chip annotations]]
[[Image:HVR-4400-Back-LowRes.png|right|200px|Photo of rear of card]]

A hybrid [[DVB-S2]] [[DVB-S2 PCI Cards|PCI card]] from [[Hauppauge]] with a PCIe 1x interface. Model 1357.

Not yet supported (Feb 2012).

There is no support currently for this card, and since it uses a demodulator for which there is not currently a driver, much more work will be required than simply adding a new board profile.

[http://www.hauppauge.co.uk/forum/showthread.php?21278-HVR-4400-linux-support Hauppauge UK Forums] (moderator wrote this in December 2010; no news by Feb 2012):

: Hauppage don't officially support it but a number of our engineers actually work on providing linux support themselves.

== Overview/Features ==

Quad-mode HD TV tuner featuring DVB-S2 HDTV, DVB-S, DVB-T, FM radio, analogue PAL/SECAM aerial TV, and S-Video, Composite and stereo audio inputs for A/V capture, and additional S-Video, Composite and stereo audio (which require separate back plane plug set, not included in the box).

Also includes black IR remote control, batteries, and IR remote control receiver with plug on rear of card.

Sockets: TV, SAT, IR, Combo socket for dongle for S-Video, composite and stereo audio.

=== Components Used ===

* [[Conexant CX23885/7/8|CX23888]] PCI Express Broadcast Audio/Video Decoder with 3D Comb and Analog IF Demodulator and integrated infrared.

=== Identification ===
<pre>
02:00.0 Multimedia video controller: Conexant Unknown device 8880 (rev 04)
Subsystem: Hauppauge computer works Inc. Unknown device c108
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fda00000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express Endpoint IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <2us, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] Vital Product Data
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
</pre>

===Images===
High resolution images with chip annotations [http://www.mcpond.co.nz/web/hauppage/HVR-4400-Front-HiRes.png front] and [http://www.mcpond.co.nz/web/hauppage/HVR-4400-Back-HiRes.png back] (600 dpi, 4298px, 9Mb each)

==Making it Work==

When [http://www.google.com/search?q=%22BOARD_HAUPPAUGE_HVR4400%22 this Google search] returns some results, some code will then exist in linux kernel source/drivers/media/video/cx23885/cx23885-cards.c , and from then you'll have a chance of getting something going. If no results, complain to Hauppage, then buy a different card, or, wait some more, or start hacking away on the source.

Feel free to add what you know.

[[Category:DVB-S2 PCI Cards]]

Gnutv

2011-09-28T01:02:47Z

Liontooth: Example command

{{lowercase|gnutv}}
A commandline utility bundled in the [[LinuxTV dvb-apps|dvb-apps]] which can, amongst other capabilities, provide DVB viewing with devices with on-board hardware decoders (formerly often referred to as "[[Full-featured Card|full featured]]" devices).

Example command to capture video and live closed captioning:

# Pipe stream to file and to the closed captioning decoder using tee
# gnutv's default value for -channels is /etc/channels.conf
gnutv -adapter $DEV -timeout $TIM -out stdout $CH | tee $FIL.mpg | \
zvbi-atsc-cc --atsc -p -m -T -1 - -2 - -X - $CH > $FIL.txt

[[Category:Software]]

Template:Lowercase

2010-04-17T05:02:34Z

Liontooth: The "technical restrictions" link should go to http://en.wikipedia.org/wiki/Wikipedia:Naming conventions (technical restrictions) -- unable to fix

<div id="RealTitleBanner">
:''The correct title of this {{{type|{{{2|article}}}}}} is '''<span id="RealTitle">{{{title|{{{1|{{LCFIRST:{{PAGENAME}}}}}}}}}}</span>'''. The initial letter is shown capitalized due to [[Wikipedia:Naming conventions (technical restrictions)#Lower case first letter|technical restrictions]].''</div><noinclude>
{{{{FULLPAGENAME}}/doc}}

</noinclude>

Template:Lowercase

2010-04-17T04:59:05Z

Liontooth:

<div id="RealTitleBanner">
:''The correct title of this {{{type|{{{2|article}}}}}} is '''<span id="RealTitle">{{{title|{{{1|{{LCFIRST:{{PAGENAME}}}}}}}}}}</span>'''. The initial letter is shown capitalized due to [[wiki/Wikipedia:Naming conventions (technical restrictions)#Lower case first letter|technical restrictions]].''</div><noinclude>
{{{{FULLPAGENAME}}/doc}}

</noinclude>

Realtek RTL2831U

2009-09-15T03:27:38Z

Liontooth: /* Infrared */

== Introduction ==

The RTL2831U is a high-performance DVB-T COFDM demodulator + USB 2.0 that integrates a COFDM demodulator, FEC decoder, de-interleavers, and USB 2.0 interface.

This chip can be found in USB devices that are sold under a numer of names: Compro VideoMate U90, TwinHan/AzureWave AD-TU200 (7047) DVB-T, Freecom, Conceptronic, and Realtek.

== Supported devices ==

The following devices are supported (numbers and names do NOT correspond):
output of grep rtl2831 /lib/modules/2.6.24-16-generic/modules.usbmap | sed -e 's/0x0000.*$//' -e 's/^.*0x0003//'

0x0bda 0x2831
0x2304 0x022b
0x13d3 0x3216
0x13d3 0x3220
0x13d3 0x3236
0x13d3 0x3238
0x13d3 0x3244
0x08dd 0x2103
0x185b 0x0100
0x185b 0x0150
0x1a46 0x1601
0x14aa 0x0160
0x14ff 0x0225

name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "DVB-T TV-Tuner Card-R"
name = "VideoMate TV U100"
name = "Vestel DVB-T TV Card"
name = "Freecom USB 2.0 DVB-T Device"
name = "DTV-DVB UDTT 7047-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047M-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047A-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 704L-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047Z-USB 2.0 DVB-T Driver"

TwinHan/AzureWave AD-TU200 (7047) DVB-T

== Get the drivers ==

To download and build the driver, issue

hg clone http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
make
make install

This code was recently synchronised with the main v4l line.

== Infrared configuration ==

A switch for the IR type is included. It can be selected using modprobe.
For example if you need type 2: unload the automatically loaded driver, and reload the good codes.

sudo modprobe -r dvb_usb_rtl2831u
sudo modprobe dvb_usb_rtl2831u ir_protocol=2

== Pending developments ==

The code cannot be included in the mainline, as the front-end and abck-end are not split (as is required)

I have started a second archive for splitting off the tuner code.
For the mxl5005s tuner, this should be straightforward, as the code
found its way into the mainstream v4l already.

However, I ran into problems with the mt2060 (which is the tuner I own).
In the function MT2060_LocateIF1 is making this hard.
This function doe some sort of calibration, and there is both internal
data from the tuner required, and input from the demodulator.

== Product links ==

* http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=147

* http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=1&tabid=242&cid=40&gid=4050&pid=CTVDIGRCU

Realtek RTL2831U

2009-09-15T03:27:04Z

Liontooth: /* Get the driver */

== Introduction ==

The RTL2831U is a high-performance DVB-T COFDM demodulator + USB 2.0 that integrates a COFDM demodulator, FEC decoder, de-interleavers, and USB 2.0 interface.

This chip can be found in USB devices that are sold under a numer of names: Compro VideoMate U90, TwinHan/AzureWave AD-TU200 (7047) DVB-T, Freecom, Conceptronic, and Realtek.

== Supported devices ==

The following devices are supported (numbers and names do NOT correspond):
output of grep rtl2831 /lib/modules/2.6.24-16-generic/modules.usbmap | sed -e 's/0x0000.*$//' -e 's/^.*0x0003//'

0x0bda 0x2831
0x2304 0x022b
0x13d3 0x3216
0x13d3 0x3220
0x13d3 0x3236
0x13d3 0x3238
0x13d3 0x3244
0x08dd 0x2103
0x185b 0x0100
0x185b 0x0150
0x1a46 0x1601
0x14aa 0x0160
0x14ff 0x0225

name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "DVB-T TV-Tuner Card-R"
name = "VideoMate TV U100"
name = "Vestel DVB-T TV Card"
name = "Freecom USB 2.0 DVB-T Device"
name = "DTV-DVB UDTT 7047-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047M-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047A-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 704L-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047Z-USB 2.0 DVB-T Driver"

TwinHan/AzureWave AD-TU200 (7047) DVB-T

== Get the drivers ==

To download and build the driver, issue

hg clone http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
make
make install

This code was recently synchronised with the main v4l line.

== Infrared ==

A switch for the IR type is included. It can be selected using modprobe.
For example if you need type 2: unload the automatically loaded driver, and reload the good codes.

sudo modprobe -r dvb_usb_rtl2831u
sudo modprobe dvb_usb_rtl2831u ir_protocol=2

== Pending developments ==

The code cannot be included in the mainline, as the front-end and abck-end are not split (as is required)

I have started a second archive for splitting off the tuner code.
For the mxl5005s tuner, this should be straightforward, as the code
found its way into the mainstream v4l already.

However, I ran into problems with the mt2060 (which is the tuner I own).
In the function MT2060_LocateIF1 is making this hard.
This function doe some sort of calibration, and there is both internal
data from the tuner required, and input from the demodulator.

== Product links ==

* http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=147

* http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=1&tabid=242&cid=40&gid=4050&pid=CTVDIGRCU

Realtek RTL2831U

2009-09-15T03:25:49Z

Liontooth:

== Introduction ==

The RTL2831U is a high-performance DVB-T COFDM demodulator + USB 2.0 that integrates a COFDM demodulator, FEC decoder, de-interleavers, and USB 2.0 interface.

This chip can be found in USB devices that are sold under a numer of names: Compro VideoMate U90, TwinHan/AzureWave AD-TU200 (7047) DVB-T, Freecom, Conceptronic, and Realtek.

== Supported devices ==

The following devices are supported (numbers and names do NOT correspond):
output of grep rtl2831 /lib/modules/2.6.24-16-generic/modules.usbmap | sed -e 's/0x0000.*$//' -e 's/^.*0x0003//'

0x0bda 0x2831
0x2304 0x022b
0x13d3 0x3216
0x13d3 0x3220
0x13d3 0x3236
0x13d3 0x3238
0x13d3 0x3244
0x08dd 0x2103
0x185b 0x0100
0x185b 0x0150
0x1a46 0x1601
0x14aa 0x0160
0x14ff 0x0225

name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "DVB-T TV-Tuner Card-R"
name = "VideoMate TV U100"
name = "Vestel DVB-T TV Card"
name = "Freecom USB 2.0 DVB-T Device"
name = "DTV-DVB UDTT 7047-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047M-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047A-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 704L-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047Z-USB 2.0 DVB-T Driver"

TwinHan/AzureWave AD-TU200 (7047) DVB-T

== Get the driver ==

The drivers posted for these cards can be found on:

http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2

This code was recently synchronised with the main v4l line.

To download and build the driver, issue

hg clone http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
make
make install

== Infrared ==

A switch for the IR type is included. It can be selected using modprobe.
For example if you need type 2: unload the automatically loaded driver, and reload the good codes.

sudo modprobe -r dvb_usb_rtl2831u
sudo modprobe dvb_usb_rtl2831u ir_protocol=2

== Pending developments ==

The code cannot be included in the mainline, as the front-end and abck-end are not split (as is required)

I have started a second archive for splitting off the tuner code.
For the mxl5005s tuner, this should be straightforward, as the code
found its way into the mainstream v4l already.

However, I ran into problems with the mt2060 (which is the tuner I own).
In the function MT2060_LocateIF1 is making this hard.
This function doe some sort of calibration, and there is both internal
data from the tuner required, and input from the demodulator.

== Product links ==

* http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=147

* http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=1&tabid=242&cid=40&gid=4050&pid=CTVDIGRCU

Realtek RTL2831U

2009-09-15T03:21:38Z

Liontooth:

The RTL2831U is a high-performance DVB-T COFDM demodulator + USB 2.0 that integrates a COFDM demodulator, FEC decoder, de-interleavers, and USB 2.0 interface.
This chip can be found in USB devices that are sold under a numer of names: Compro VideoMate U90,
TwinHan/AzureWave AD-TU200 (7047) DVB-T , Freecom , Conceptronic , and also Realtek.

The drivers posted for these cards can be found on:
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2

This code is recently synchronised with the main v4l line.
A switch for the IR type is included. It can be selected using modprobe.
For example if you need type 2: unload the automatically loaded driver, and reload the good codes.

sudo modprobe -r dvb_usb_rtl2831u
sudo modprobe dvb_usb_rtl2831u ir_protocol=2

== Supported devices ==

The following devices are supported (numbers and names do NOT correspond):
output of grep rtl2831 /lib/modules/2.6.24-16-generic/modules.usbmap | sed -e 's/0x0000.*$//' -e 's/^.*0x0003//'

0x0bda 0x2831
0x2304 0x022b
0x13d3 0x3216
0x13d3 0x3220
0x13d3 0x3236
0x13d3 0x3238
0x13d3 0x3244
0x08dd 0x2103
0x185b 0x0100
0x185b 0x0150
0x1a46 0x1601
0x14aa 0x0160
0x14ff 0x0225

name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "DVB-T TV-Tuner Card-R"
name = "VideoMate TV U100"
name = "Vestel DVB-T TV Card"
name = "Freecom USB 2.0 DVB-T Device"
name = "DTV-DVB UDTT 7047-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047M-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047A-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 704L-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047Z-USB 2.0 DVB-T Driver"

TwinHan/AzureWave AD-TU200 (7047) DVB-T

== Pending developments ==

The code cannot be included in the mainline, as the front-end and abck-end are not split (as is required)

I have started a second archive for splitting off the tuner code.
For the mxl5005s tuner, this should be straightforward, as the code
found its way into the mainstream v4l already.

However, I ran into problems with the mt2060 (which is the tuner I own).
In the function MT2060_LocateIF1 is making this hard.
This function doe some sort of calibration, and there is both internal
data from the tuner required, and input from the demodulator.

== Get the driver ==

To download and build the driver, issue

hg clone http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
make
make install

== Product links ==

* http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=147

* http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=1&tabid=242&cid=40&gid=4050&pid=CTVDIGRCU

Realtek RTL2831U

2009-09-15T03:19:04Z

Liontooth: Typo

The RTL2831U is a high-performance DVB-T COFDM demodulator + USB 2.0 that integrates a COFDM demodulator, FEC decoder, de-interleavers, and USB 2.0 interface.
This chip can be found in USB devices that are sold under a numer of names: Compro VideoMate U90,
TwinHan/AzureWave AD-TU200 (7047) DVB-T , Freecom , Conceptronic , and also Realtek.

The drivers posted for these cards can be found on:
http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2

This code is recently synchronised with the main v4l line.
A switch for the IR type is included. It can be selected using modprobe.
For example if you need type 2: unload the automatically loaded driver, and reload the good codes.

sudo modprobe -r dvb_usb_rtl2831u
sudo modprobe dvb_usb_rtl2831u ir_protocol=2

-----------------
The following devices are supported (numbers and names do NOT correspond):
output of grep rtl2831 /lib/modules/2.6.24-16-generic/modules.usbmap | sed -e 's/0x0000.*$//' -e 's/^.*0x0003//'

0x0bda 0x2831
0x2304 0x022b
0x13d3 0x3216
0x13d3 0x3220
0x13d3 0x3236
0x13d3 0x3238
0x13d3 0x3244
0x08dd 0x2103
0x185b 0x0100
0x185b 0x0150
0x1a46 0x1601
0x14aa 0x0160
0x14ff 0x0225

name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "RTL2831U DVB-T USB2.0 DEVICE"
name = "DVB-T TV-Tuner Card-R"
name = "VideoMate TV U100"
name = "Vestel DVB-T TV Card"
name = "Freecom USB 2.0 DVB-T Device"
name = "DTV-DVB UDTT 7047-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047M-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047A-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 704L-USB 2.0 DVB-T Driver"
name = "DTV-DVB UDTT 7047Z-USB 2.0 DVB-T Driver"

TwinHan/AzureWave AD-TU200 (7047) DVB-T

-------------
The code cannot be included in the mainline, as the front-end and abck-end are not split (as is required)

I have started a second archive for splitting off the tuner code.
For the mxl5005s tuner, this should be straightforward, as the code
found its way into the mainstream v4l already.

However, I ran into problems with the mt2060 (which is the tuner I own).
In the function MT2060_LocateIF1 is making this hard.
This function doe some sort of calibration, and there is both internal
data from the tuner required, and input from the demodulator.

--

For those of you that are not familiar with development:

hg clone http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
make
make install

should be giving a proper driver at all times.

--

http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=147

http://www.conceptronic.net/site/desktopdefault.aspx?tabindex=1&tabid=242&cid=40&gid=4050&pid=CTVDIGRCU

NXP SAA716x

2009-09-15T02:55:23Z

Liontooth: /* Saa7162 IC chip information */

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The Saa7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

See [[Saa7162 devices]]. There are also some DVB-S2 cards based on the SAA7160.

=== Saa7162 driver development ===

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

The Saa716x driver is expected to support the following PCIe chips:

* Saa7160
* Saa7161
* Saa7162

Manu Abraham's Saa716x development repository is at http://jusst.de/hg/saa716x -- the driver has not yet been released, but is open for testing.

== Saa7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP Saa7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge WinTV-HVR-2200]] and [[Hauppauge_WinTV-HVR-2250]].

=== Saa7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The Saa7164 driver does not support the Saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

NXP SAA716x

2009-09-15T02:51:04Z

Liontooth: /* Saa7162 driver development */

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The Saa7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

=== Saa7162 driver development ===

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

The SAA716x driver is expected to support the following PCIe chips:

* Saa7160
* Saa7161
* Saa7162

The SAA716x development repository is at http://jusst.de/hg/saa716x

The Linux driver for the Saa7162 is still to be released.

== Saa7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP Saa7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge WinTV-HVR-2200]] and [[Hauppauge_WinTV-HVR-2250]].

=== Saa7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The Saa7164 driver does not support the Saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

Hauppauge WinTV-HVR-2250

2009-09-15T02:39:01Z

Liontooth: /* Making it Work */

[[Image:WinTV_HVR-2250.jpg|thumb|right|250px|caption]]

An [[ATSC]] [[ATSC PCIe Cards|PCIe card]] from [[Hauppauge]].

== Overview/Features ==

Dual hybrid digital/analog tuners, low profile.

* Single slot PCI Express (PCIe) X1 board, half height.
* Two analog tuners, each with their own hardware encoders
* Two digital TV receivers for ATSC or clear QAM
* Dual built-in hardware MPEG-2 encoders.

=== Components Used ===

* [[NXP_SAA716x|NXP SAA7164]]

* Pair of [[NXP TDA18271HD]] tuner chips.

Could someone who has this card please take a good look at the board and list all the chips here?

The REV C2F2 has
* [[NXP_SAA716x|NXP SAA7164E/3]]
* Pair of [[Conexant]] CX24228-21Z demodulators

===Identification===

===Other Images===

Top view
[[File:WinTV_HVR-2250.jpg|200px]]

== Making it Work ==

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP Saa7164 PCIe A/V bridge used by the Hauppauge HVR-2250 card. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development continues at http://www.steventoth.net/blog/products/hvr-2250/

=== Firmware ===

The windows driver and linux firmware extraction scripts are up on
http://www.steventoth.net/linux/hvr22xx

=== Drivers ===

Drivers are expected to be included in Linux 2.6.32.

In the meantime, for stable tree hg clone http://kernellabs.com/hg/saa7164-stable/

For Development tree hg clone http://kernellabs.com/hg/~stoth/saa7164-dev/

then... make menuconfig edit as needed make make install reboot

=== Sample Kernel Output ===

''provide the relevant portion of dmesg here''

===Remote Controller Support===

==External Links==

* [http://www.hauppauge.com/site/products/data_hvr2250.html Hauppauge Product Page]

[[Category:ATSC PCIe Cards]]

Hauppauge WinTV-HVR-2250

2009-09-15T02:38:31Z

Liontooth: Driver submitted to lkml

[[Image:WinTV_HVR-2250.jpg|thumb|right|250px|caption]]

An [[ATSC]] [[ATSC PCIe Cards|PCIe card]] from [[Hauppauge]].

== Overview/Features ==

Dual hybrid digital/analog tuners, low profile.

* Single slot PCI Express (PCIe) X1 board, half height.
* Two analog tuners, each with their own hardware encoders
* Two digital TV receivers for ATSC or clear QAM
* Dual built-in hardware MPEG-2 encoders.

=== Components Used ===

* [[NXP_SAA716x|NXP SAA7164]]

* Pair of [[NXP TDA18271HD]] tuner chips.

Could someone who has this card please take a good look at the board and list all the chips here?

The REV C2F2 has
* [[NXP_SAA716x|NXP SAA7164E/3]]
* Pair of [[Conexant]] CX24228-21Z demodulators

===Identification===

===Other Images===

Top view
[[File:WinTV_HVR-2250.jpg|200px]]

== Making it Work ==

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP Saa7164 PCIe A/V bridge used by the Hauppauge HVR-2250 card. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

See instructions at [[Hauppauge WinTV-HVR-2200]].

Development continues at http://www.steventoth.net/blog/products/hvr-2250/

=== Firmware ===

The windows driver and linux firmware extraction scripts are up on
http://www.steventoth.net/linux/hvr22xx

=== Drivers ===

Drivers are expected to be included in Linux 2.6.32.

In the meantime, for stable tree hg clone http://kernellabs.com/hg/saa7164-stable/

For Development tree hg clone http://kernellabs.com/hg/~stoth/saa7164-dev/

then... make menuconfig edit as needed make make install reboot

=== Sample Kernel Output ===

''provide the relevant portion of dmesg here''

===Remote Controller Support===

==External Links==

* [http://www.hauppauge.com/site/products/data_hvr2250.html Hauppauge Product Page]

[[Category:ATSC PCIe Cards]]

NXP SAA716x

2009-09-15T02:24:37Z

Liontooth: /* Saa7164 IC chip information */

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The Saa7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

=== Saa7162 driver development ===

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

This means that a Linux driver for the Saa7162 is still to be released. Hopefully the remaining issues with the chipset can be resolved soon and then device level support for PCIe cards incorporating the saa7162 can begin.

'''Current Status (as of Nov 21/08) and link to driver''': http://marc.info/?l=linux-dvb&m=122729999014286&w=2

== Saa7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP Saa7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge WinTV-HVR-2200]] and [[Hauppauge_WinTV-HVR-2250]].

=== Saa7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The Saa7164 driver does not support the Saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

NXP SAA716x

2009-09-15T02:23:21Z

Liontooth: /* Saa7162 Driver Development */

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The Saa7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

=== Saa7162 driver development ===

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

This means that a Linux driver for the Saa7162 is still to be released. Hopefully the remaining issues with the chipset can be resolved soon and then device level support for PCIe cards incorporating the saa7162 can begin.

'''Current Status (as of Nov 21/08) and link to driver''': http://marc.info/?l=linux-dvb&m=122729999014286&w=2

== Saa7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP Saa7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge_WinTV-HVR-2250]].

=== Saa7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The Saa7164 driver does not support the Saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

NXP SAA716x

2009-09-15T02:22:59Z

Liontooth:

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The Saa7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

=== Saa7162 Driver Development ===

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

This means that a Linux driver for the Saa7162 is still to be released. Hopefully the remaining issues with the chipset can be resolved soon and then device level support for PCIe cards incorporating the saa7162 can begin.

'''Current Status (as of Nov 21/08) and link to driver''': http://marc.info/?l=linux-dvb&m=122729999014286&w=2

== Saa7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP Saa7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge_WinTV-HVR-2250]].

=== Saa7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The Saa7164 driver does not support the Saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

NXP SAA716x

2009-09-15T02:21:38Z

Liontooth: Reorganize sections to avoid driver confusion

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

== Introduction ==

In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

== Saa7162 IC chip information ==

The SAA7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

== SAA7162 Driver Development ==

Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

This means that a Linux driver for the saa7162 is still to be released. Hopefully the remaining issues with the chipset can be resolved soon and then device level support for PCIe cards incorporating the saa7162 can begin.

'''Current Status (as of Nov 21/08) and link to driver''': http://marc.info/?l=linux-dvb&m=122729999014286&w=2

== SAA7164 IC chip information ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP SAA7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge_WinTV-HVR-2250]].

=== SAA7164 driver ===

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The saa7164 driver does not support the saa7160/61/62 chips.

==External Links==
*
[[Category:Chipsets]]

NXP SAA716x

2009-09-15T02:18:24Z

Liontooth: /* SAA7164 IC chip information */

A family [[PCIe interface chipsets|PCIe interface chipset]] from [[NXP Semiconductors]].

The SAA7160/SAA7161/SAA7162 IC parts will be supported by the SAA716x kernel driver module (see current status below).

==Introduction==
In March 2005, Philips Semiconductors announced "the industry's first integrated PCI Express dual global video and stereo decoder for digital home PC desktops and notebooks" ([http://www.electronicstalk.com/news/phi/phi309.html press release]). The new analog decoder chip, the saa7162, uses the increased bandwidth of the PCI Express bus to capture to two simultaneous analog channels of live tv or baseband video (cf. [http://www-us.semiconductors.philips.com/acrobat/literature/9397/75015389.pdf product flyer]) or up to four independent simultaneous digital TV streams (cf. [http://www.nxp.com/acrobat_download/literature/9397/75015302.pdf Philips/NXP SAA7162 product brief]).

In Oct 2006, NXP created a saa7162 product page that includes, amongst other information, an 18 page "preliminary short data sheet" for download:
[http://www.nxp.com/pip/SAA7162E_V1_R5_G.html SAA7162 Product Description].

The PCI-SIG lists SAA7162 (dual A/V decoder) and SAA7160/SAA7161 (multimedia A/V bridge) as PCIe devices. According to PCIe specs there are two types of PCIe devices; Type 1, which categorize normal PCIe bridge devices, and Type 0, which categorize devices which have a specific/customized programmable interface. Unfortunately, the PCIe spec is not very detailed when it comes to Type 0 devices, and it is indeed this category that the SAA7160/1/2 reside.

==Saa7162 IC chip information==
The SAA7162 is a PCI Express bridge with integrated dual stream A/V decoder. The device is a single lane PCIe device opertaion at 2.5G sample/s.

The dual logical Audio/Video decoder support 10 bit A/D conversion, enhanced PAL/NTSC comb filtering, a versatile VBI data processing, more sophisticated scaling alogrithms, support of High Definition component video, picture improvement processing, more robustness with VCR-type signals, and increased audio functionallity like SPDIF In/Out and an intergrated audio sample rate coverter from 32Khz to 44Khz or 48Khz.Each channels has its own silent I2C bus for controlling sensitive tuner devices. One of the channels provides an IR interface.

Aside to the dual A/V decoder, there is a versatile I/O block, featuring PHI, SPI, I2C-bus,32 GPIO lines. The PHI is a fast parallel bus interface. The SPI-bus is a high speed serial bus interface. The two I2C bus interfaces operate at high speed grade.

The Saa7162 is a highly intergrated circuit for e.g TV insertion inside PC system. The Muti Standard TV decoder covered all Video color standards like PAL, NTSC and SECAM and Sound standards like Dual FM, NICAM, BTSC and EIAJ, Addtional to the TV decider function a digital IF demodulator, a FM Radio decoder, standard interfaces for digital Video and Audio, Remote control receiver/transmission processing and a high speed programming port allows high intergrated system solutions for muti media application.

== SAA7164 IC chip information and driver ==

A more complex IC that incorporates a built-in MPEG2 encoder.

The NXP SAA7164 integrates up to 8 standalone chips: two IF demodulators, two PAL/NTSC/SECAM decoders, two stereo decoders, plus two multi-format compression engines

[http://www.nxp.com/acrobat/literature/9397/75015870.pdf SAA7164 brochure]

Used in the [[Hauppauge_WinTV-HVR-2250]].

In September 2009, Steven Toth at [http://kernellabs.com kernellabs] submitted code to the linux kernel mailing list that adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. See instructions at [[Hauppauge WinTV-HVR-2200]]. Note that support is still limited to DVB-T / ATSC / QAM digital TV only; there is no analog support yet.

Development is continuing; see http://www.steventoth.net/blog/products/hvr-2250/ and http://www.kernellabs.com.

The saa7164 driver does not support the saa7160/61/62 chips.

==Driver Development==
Philips announced in their [http://www.nxp.com/applications/pc_pda/pc_tv/dual_analog_pc_tv_receiver/index.html reference design] that they had already written a Linux driver. In May 2007, they finally sent the code to [http://www.interlink.com.au/rad/quattros Richard Dale] (without an [[NDA]]) and Manu Abraham, who is now writing a GPL'd driver under an [[NDA]] (the terms of which are not widely known). See the [http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017856.html full discussion on linux-dvb].

While development has progressed, it appears that the information available/provided does not fully document some aspects of this chipset, and hence some areas of development have been problematic. Unfortunately, it appears that before NXP will consider providing additional assistance towards Linux driver support for the chipset, they wish to determine whether it is worth their while by gaining some measure of the potential future user base that Linux drivers will actually provide. Representatives from device vendors Azurewave and Hauppauge have outlined that they will try to assist LinuxTV in its effort to obtain more assistance in this matter. [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019452.html] [http://www.linuxtv.org/pipermail/linux-dvb/2007-August/019463.html].

This means that a Linux driver for the saa7162 is still yet to be released. Hopefully the remaining issues with the chipset can be resolved soon and then device level support for PCIe cards incorporating the saa7162 can begin.

'''Current Status (as of Nov 21/08) and link to driver''': http://marc.info/?l=linux-dvb&m=122729999014286&w=2

==External Links==
*
[[Category:Chipsets]]

Text capture

2009-05-24T15:09:18Z

Liontooth: /* ccextractor */

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

===Analog television===
The [http://en.wikipedia.org/wiki/VBI vertical blanking interval (VBI)] is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the VBI on lines 17 through 20.

In North America, which follows the NTSC standard, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the VBI.

===Digital television (DTV) ===
====DVB====
The European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

The DVB standard transmits sliced VBI data in a separate elementary stream.

====ATSC====
The [http://www.atsc.org/standards/a53.html A/53 ATSC Digital Television Standard] covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B]. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Digital Television Closed Captioning FAQ]for details.

EIA-708 specifies the transmission of CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex from there. A freestanding CC capture application would still need to tune in and choose a program ID. To complicate matters further,
EIA-708 allows both old style EIA-608-compatible closed caption data as well as the newer DTVCC.

Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==Devices Usable With Text==
===bt8x8 devices===
Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent text capture capability for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===cx88 devices===
The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

The latest test with kernel 2.6.27.2, NTSC closed caption is working, with a small patch published by Rafael Diniz in a [http://marc.info/?l=linux-video&m=122469689710030&w=2 22 October 2008 email]. This patch hopefully will be applied soon.

===ivtv devices===
For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the [http://ivtvdriver.org ivtv] wiki.

'''IVTV''' provides generic VBI data via a VBI Linux device. As EIA-608 closed caption data is among the VBI data, you can get it from the VBI device. '''IVTV''' provides the VBI data in two different formats -- raw and sliced. the raw mode is all of the VBI lines, with 720 luminosity samples line. The sliced format has it decoded into data bytes, with selectable VBI lines.

In addition, '''IVTV''' can embed VBI data in the MPEG stream you get from the video Linux device. It embeds it in Private Stream 1 of the MPEG stream. This is not a standard format; it is an IVTV invention. A few programs, including '''mythtv''' and '''ccextractor''' know the IVTV embedded VBI format with respect to EIA-608 closed captioning. Bryan Henderson (bryanh@giraffe-data.com) has a patch (May 2008) for Mplayer that makes it do so also.

The README.vbi in a current ivtv release has lots of details.

With a PVR-250, '''IVTV''' provides the VBI device and controls to put it in either raw mode or sliced CC. (Based on my own experimentation - Bryan Henderson).

Older '''IVTV''' (Before version 0.10) crashes when you read the VBI device if you put the device into sliced mode and you load '''IVTV''' with the autoload=0 option. Bryan Henderson (bryanh@giraffe-data.com) has a fix for this divide by zero bug.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the '''IVTV''' mailing list suggests it can provide CC, VPS and WSS data with the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi function for PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi with pvr150/500.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently uses the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===saa713x devices===
Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent text capture capability under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

==Applications==
===alevt===
[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===ccextractor===

[http://ccextractor.sourceforge.net '''ccextractor'''] can extract closed captions from a variety of kinds of input streams and render the information in various forms. It understands as input DVB and IVTV format, and can produce as output SRT or SAMI (standard subtitle file formats) or raw captions in DVB format.

ccextractor is also excellent for extracting the closed captioning from DVDs and DVD images (such as the cdr images created by OSX's DiskImage utility) or ts files. The software is still in beta and the developers are active, so help them improve the application.

===gstreamer===
The application gstreamer works with closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===MPlayer===
Scott Larson has (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for '''mplayer''' to display EIA-708 closed captioning (e.g. from a digital TV broadcast). Specifically, the patch uses the EIA-608 compatible subformat; it cannot use the DTVCC data. See the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for more information.

Bryan Henderson (bryanh@giraffe-data.com) has (May 2008) written a patch for '''mplayer''' to make it do closed captioning based on IVTV MPEG embedded VBI (EIA608) data in its MPEG input.

===mtt===
A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===Mythtv===

Mythtv's native player can display closed captions encoded into an MPEG-2 stream in the IVTV format.

===nxtvepg===
The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===
The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===
tvtime displays closed captioning with [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===
[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===
The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.32 ATSC is also supported. I don't know if the V4L2 sliced API is supported yet (please add if you know).

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] understands the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".
The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The zvbi library currently does not understand the American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B].

Michael Schimek writes that A/53 specifies the transmission of "CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc it might suffice."

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==== zvbi-ntsc-cc ====
:Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

:Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==== zvbi-atsc-cc ====
:Libzvbi 0.2.32 added an improved version of zvbi-ntsc-cc which can record EIA-608 and EIA-708 caption from ATSC devices.

==Technical background==
===Displaying captured text===
To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===
Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.
[[Category:Development]]
[[Category:Hardware]]
[[Category:Technology]]

Text capture

2009-05-24T15:08:33Z

Liontooth: /* ccextractor */

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

===Analog television===
The [http://en.wikipedia.org/wiki/VBI vertical blanking interval (VBI)] is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the VBI on lines 17 through 20.

In North America, which follows the NTSC standard, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the VBI.

===Digital television (DTV) ===
====DVB====
The European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

The DVB standard transmits sliced VBI data in a separate elementary stream.

====ATSC====
The [http://www.atsc.org/standards/a53.html A/53 ATSC Digital Television Standard] covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B]. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Digital Television Closed Captioning FAQ]for details.

EIA-708 specifies the transmission of CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex from there. A freestanding CC capture application would still need to tune in and choose a program ID. To complicate matters further,
EIA-708 allows both old style EIA-608-compatible closed caption data as well as the newer DTVCC.

Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==Devices Usable With Text==
===bt8x8 devices===
Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent text capture capability for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===cx88 devices===
The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

The latest test with kernel 2.6.27.2, NTSC closed caption is working, with a small patch published by Rafael Diniz in a [http://marc.info/?l=linux-video&m=122469689710030&w=2 22 October 2008 email]. This patch hopefully will be applied soon.

===ivtv devices===
For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the [http://ivtvdriver.org ivtv] wiki.

'''IVTV''' provides generic VBI data via a VBI Linux device. As EIA-608 closed caption data is among the VBI data, you can get it from the VBI device. '''IVTV''' provides the VBI data in two different formats -- raw and sliced. the raw mode is all of the VBI lines, with 720 luminosity samples line. The sliced format has it decoded into data bytes, with selectable VBI lines.

In addition, '''IVTV''' can embed VBI data in the MPEG stream you get from the video Linux device. It embeds it in Private Stream 1 of the MPEG stream. This is not a standard format; it is an IVTV invention. A few programs, including '''mythtv''' and '''ccextractor''' know the IVTV embedded VBI format with respect to EIA-608 closed captioning. Bryan Henderson (bryanh@giraffe-data.com) has a patch (May 2008) for Mplayer that makes it do so also.

The README.vbi in a current ivtv release has lots of details.

With a PVR-250, '''IVTV''' provides the VBI device and controls to put it in either raw mode or sliced CC. (Based on my own experimentation - Bryan Henderson).

Older '''IVTV''' (Before version 0.10) crashes when you read the VBI device if you put the device into sliced mode and you load '''IVTV''' with the autoload=0 option. Bryan Henderson (bryanh@giraffe-data.com) has a fix for this divide by zero bug.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the '''IVTV''' mailing list suggests it can provide CC, VPS and WSS data with the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi function for PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi with pvr150/500.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently uses the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===saa713x devices===
Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent text capture capability under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

==Applications==
===alevt===
[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===ccextractor===

[http://ccextractor.sourceforge.net '''ccextractor'''] can extract closed captions from a variety of kinds of input streams and render the information in various forms. It understands as input DVB and IVTV format, and can produce as output SRT or SAMI (standard subtitle file formats) or raw captions in DVB format.

ccextractor is also excellent for extracting the closed captioning from DVDs and DVD images (such as the cdr images created by OSX's DiskImage utility). The software is still in beta and the developers are active, so help them improve the application.

===gstreamer===
The application gstreamer works with closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===MPlayer===
Scott Larson has (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for '''mplayer''' to display EIA-708 closed captioning (e.g. from a digital TV broadcast). Specifically, the patch uses the EIA-608 compatible subformat; it cannot use the DTVCC data. See the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for more information.

Bryan Henderson (bryanh@giraffe-data.com) has (May 2008) written a patch for '''mplayer''' to make it do closed captioning based on IVTV MPEG embedded VBI (EIA608) data in its MPEG input.

===mtt===
A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===Mythtv===

Mythtv's native player can display closed captions encoded into an MPEG-2 stream in the IVTV format.

===nxtvepg===
The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===
The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===
tvtime displays closed captioning with [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===
[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===
The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.32 ATSC is also supported. I don't know if the V4L2 sliced API is supported yet (please add if you know).

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] understands the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".
The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The zvbi library currently does not understand the American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B].

Michael Schimek writes that A/53 specifies the transmission of "CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc it might suffice."

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==== zvbi-ntsc-cc ====
:Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

:Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==== zvbi-atsc-cc ====
:Libzvbi 0.2.32 added an improved version of zvbi-ntsc-cc which can record EIA-608 and EIA-708 caption from ATSC devices.

==Technical background==
===Displaying captured text===
To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===
Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.
[[Category:Development]]
[[Category:Hardware]]
[[Category:Technology]]

Text capture

2009-05-02T15:20:50Z

Liontooth: /* zvbi */

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

===Analog television===
The [http://en.wikipedia.org/wiki/VBI vertical blanking interval (VBI)] is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the VBI on lines 17 through 20.

In North America, which follows the NTSC standard, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the VBI.

===Digital television (DTV) ===
====DVB====
The European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

The DVB standard transmits sliced VBI data in a separate elementary stream.

====ATSC====
The [http://www.atsc.org/standards/a53.html A/53 ATSC Digital Television Standard] covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B]. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Digital Television Closed Captioning FAQ]for details.

EIA-708 specifies the transmission of CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex from there. A freestanding CC capture application would still need to tune in and choose a program ID. To complicate matters further,
EIA-708 allows both old style EIA-608-compatible closed caption data as well as the newer DTVCC.

Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==Devices Usable With Text==
===bt8x8 devices===
Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent text capture capability for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===cx88 devices===
The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

The latest test with kernel 2.6.27.2, NTSC closed caption is working, with a small patch published by Rafael Diniz in a [http://marc.info/?l=linux-video&m=122469689710030&w=2 22 October 2008 email]. This patch hopefully will be applied soon.

===ivtv devices===
For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the [http://ivtvdriver.org ivtv] wiki.

'''IVTV''' provides generic VBI data via a VBI Linux device. As EIA-608 closed caption data is among the VBI data, you can get it from the VBI device. '''IVTV''' provides the VBI data in two different formats -- raw and sliced. the raw mode is all of the VBI lines, with 720 luminosity samples line. The sliced format has it decoded into data bytes, with selectable VBI lines.

In addition, '''IVTV''' can embed VBI data in the MPEG stream you get from the video Linux device. It embeds it in Private Stream 1 of the MPEG stream. This is not a standard format; it is an IVTV invention. A few programs, including '''mythtv''' and '''ccextractor''' know the IVTV embedded VBI format with respect to EIA-608 closed captioning. Bryan Henderson (bryanh@giraffe-data.com) has a patch (May 2008) for Mplayer that makes it do so also.

The README.vbi in a current ivtv release has lots of details.

With a PVR-250, '''IVTV''' provides the VBI device and controls to put it in either raw mode or sliced CC. (Based on my own experimentation - Bryan Henderson).

Older '''IVTV''' (Before version 0.10) crashes when you read the VBI device if you put the device into sliced mode and you load '''IVTV''' with the autoload=0 option. Bryan Henderson (bryanh@giraffe-data.com) has a fix for this divide by zero bug.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the '''IVTV''' mailing list suggests it can provide CC, VPS and WSS data with the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi function for PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi with pvr150/500.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently uses the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===saa713x devices===
Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent text capture capability under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

==Applications==
===alevt===
[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===ccextractor===

[http://ccextractor.sourceforge.net '''ccextractor'''] can extract closed captions from a variety of kinds of input streams and render the information in various forms. It understands as input DVB and IVTV format, and can produce as output SRT or SAMI (standard subtitle file formats) or raw captions in DVB format.

===gstreamer===
The application gstreamer works with closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===MPlayer===
Scott Larson has (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for '''mplayer''' to display EIA-708 closed captioning (e.g. from a digital TV broadcast). Specifically, the patch uses the EIA-608 compatible subformat; it cannot use the DTVCC data. See the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for more information.

Bryan Henderson (bryanh@giraffe-data.com) has (May 2008) written a patch for '''mplayer''' to make it do closed captioning based on IVTV MPEG embedded VBI (EIA608) data in its MPEG input.

===mtt===
A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===Mythtv===

Mythtv's native player can display closed captions encoded into an MPEG-2 stream in the IVTV format.

===nxtvepg===
The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===
The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===
tvtime displays closed captioning with [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===
[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===
The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.32 ATSC is also supported. I don't know if the V4L2 sliced API is supported yet (please add if you know).

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] understands the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".
The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The zvbi library currently does not understand the American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B].

Michael Schimek writes that A/53 specifies the transmission of "CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc it might suffice."

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==== zvbi-ntsc-cc ====
:Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

:Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==== zvbi-atsc-cc ====
:Libzvbi 0.2.32 added an improved version of zvbi-ntsc-cc which can record EIA-608 and EIA-708 caption from ATSC devices.

==Technical background==
===Displaying captured text===
To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===
Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.

Text capture

2009-05-02T15:16:01Z

Liontooth: /* zvbi */

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

===Analog television===
The [http://en.wikipedia.org/wiki/VBI vertical blanking interval (VBI)] is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the VBI on lines 17 through 20.

In North America, which follows the NTSC standard, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the VBI.

===Digital television (DTV) ===
====DVB====
The European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

The DVB standard transmits sliced VBI data in a separate elementary stream.

====ATSC====
The [http://www.atsc.org/standards/a53.html A/53 ATSC Digital Television Standard] covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B]. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Digital Television Closed Captioning FAQ]for details.

EIA-708 specifies the transmission of CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex from there. A freestanding CC capture application would still need to tune in and choose a program ID. To complicate matters further,
EIA-708 allows both old style EIA-608-compatible closed caption data as well as the newer DTVCC.

Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==Devices Usable With Text==
===bt8x8 devices===
Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent text capture capability for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===cx88 devices===
The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

The latest test with kernel 2.6.27.2, NTSC closed caption is working, with a small patch published by Rafael Diniz in a [http://marc.info/?l=linux-video&m=122469689710030&w=2 22 October 2008 email]. This patch hopefully will be applied soon.

===ivtv devices===
For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the [http://ivtvdriver.org ivtv] wiki.

'''IVTV''' provides generic VBI data via a VBI Linux device. As EIA-608 closed caption data is among the VBI data, you can get it from the VBI device. '''IVTV''' provides the VBI data in two different formats -- raw and sliced. the raw mode is all of the VBI lines, with 720 luminosity samples line. The sliced format has it decoded into data bytes, with selectable VBI lines.

In addition, '''IVTV''' can embed VBI data in the MPEG stream you get from the video Linux device. It embeds it in Private Stream 1 of the MPEG stream. This is not a standard format; it is an IVTV invention. A few programs, including '''mythtv''' and '''ccextractor''' know the IVTV embedded VBI format with respect to EIA-608 closed captioning. Bryan Henderson (bryanh@giraffe-data.com) has a patch (May 2008) for Mplayer that makes it do so also.

The README.vbi in a current ivtv release has lots of details.

With a PVR-250, '''IVTV''' provides the VBI device and controls to put it in either raw mode or sliced CC. (Based on my own experimentation - Bryan Henderson).

Older '''IVTV''' (Before version 0.10) crashes when you read the VBI device if you put the device into sliced mode and you load '''IVTV''' with the autoload=0 option. Bryan Henderson (bryanh@giraffe-data.com) has a fix for this divide by zero bug.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the '''IVTV''' mailing list suggests it can provide CC, VPS and WSS data with the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi function for PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi with pvr150/500.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently uses the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===saa713x devices===
Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent text capture capability under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

==Applications==
===alevt===
[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===ccextractor===

[http://ccextractor.sourceforge.net '''ccextractor'''] can extract closed captions from a variety of kinds of input streams and render the information in various forms. It understands as input DVB and IVTV format, and can produce as output SRT or SAMI (standard subtitle file formats) or raw captions in DVB format.

===gstreamer===
The application gstreamer works with closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===MPlayer===
Scott Larson has (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for '''mplayer''' to display EIA-708 closed captioning (e.g. from a digital TV broadcast). Specifically, the patch uses the EIA-608 compatible subformat; it cannot use the DTVCC data. See the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for more information.

Bryan Henderson (bryanh@giraffe-data.com) has (May 2008) written a patch for '''mplayer''' to make it do closed captioning based on IVTV MPEG embedded VBI (EIA608) data in its MPEG input.

===mtt===
A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===Mythtv===

Mythtv's native player can display closed captions encoded into an MPEG-2 stream in the IVTV format.

===nxtvepg===
The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===
The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===
tvtime displays closed captioning with [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===
[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===
The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.21 the V4L2 sliced API and ATSC are not yet supported.

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] understands the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".
The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The zvbi library currently does not understand the American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B].

Michael Schimek writes that A/53 specifies the transmission of "CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc it might suffice."

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

==== zvbi-ntsc-cc ====
:Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

:Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==== zvbi-atsc-cc ====
:Libzvbi 0.2.32 added an improved version of zvbi-ntsc-cc which can record EIA-608 and EIA-708 caption from ATSC devices.

==Technical background==
===Displaying captured text===
To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===
Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.

V4L channel script

2009-05-02T14:51:01Z

Liontooth:

==The channel scripts==

===Introduction===

This simple script, with its companion timestamper, is designed to capture television programs on a regular schedule and store the recordings in a dated directory tree along with the closed captioning text files. Because the scripts are so elementary, they are very easy to debug, and the script has been running flawlessly for more than a year now.

The script is designed to handle several capture cards for simultaneous capture, and jobs are scheduled per card in a cron job or issued manually for a single program. Files are saved to the first drive with "tv" in its name and at least 1GB of free space.

The use of [http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html bash] is elementary and can surely be improved on.

===Hardware===

My setup is an amd64 motherboard with on-board NICs, sound, and video, and five PCI slots ([http://www.giga-byte.com/MotherBoard/Products/Products_Spec_GA-K8NS%20Ultra-939.htm Gigabyte K8NS Ultra-939]), so there's lots of room for grabber cards. It currently uses three [[LifeView FlyVideo3000FM NTSC]] and two [[LifeView FlyTV_Platinum]] (saa7134) cards. I chose them because I can get sound directly off the cards and don't need a patch cable for each one to a sound card.

The three capture cards are loaded as follows:

saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1

The CPU is an AMD Athlon 64 dual core 4600+ (939); each mencoder session uses about 20% of the CPU. Results from five simultaneous capture is now excellent. The script assumes you get the signal off the air; cf. the "us-bcast" parameter.

I would like to switch to [[PcHDTV |pcHDTV-3000]], but these cards don't have closed captioning support yet.

I capture to SATA drives; the board has support for four of these. The OS is installed on a PATA drive.

===Software===

The OS is Debian sid with a 2.6.18-1 kernel. I generally leave the OS alone, but occasionally update some of the applications.

Mencoder is used to grab and compress the footage, using DIVX and mp3lame and an avi wrapper (suggestions for improvements are welcome). I'm currently running [http://www.debian-multimedia.org/ Christian Marillat's] unofficial 1:1.0-pre8cvs20061002-0.0 Debian package.

We don't don't view the footage on the capture machine, but use [http://nfs.sourceforge.net/ NFS] to view the captured files on other machines. On OSX, you can view the avi files with VLC; Windows is untested, but the files should play after installing the DIVX codec. Users can be given access to the recording machine's crontab. On X11, [http://docs.kde.org/development/en/kdeadmin/kcron/index.html kcron] provides a user-friendly interface. The status of the capture machine can usefully be monitored with gnome-system-monitor.

For listings, we use [http://freeguide-tv.sourceforge.net/ Freeguide].

===Capture script===

<pre>

#!/bin/bash
#
# /usr/local/bin/channel
#
# Script to record analog television programs to .avi files, using mencoder, and
# the associated closed captioning in a separate identically named .txt file
#
# You need to include /usr/local/bin in cron's PATH (see kcron's Variables)
# Use the bash interpreter -- /bin/bash, not /bin/sh
#
# Usage: channel <channel number> <duration> <title> <capture card number>
#
# For instance,
#
# channel 28, 30min, "BBC World News", 1
#
# Input parameter rules:
# * commas are optional
# * give duration (recording time) in minutes
# * the word "min" (for minutes) is optional
# * a space signals a new parameter
# * enclose multi-word titles in quotes
# * don't use apostrophes in titles -- messes up searching of captured text
# * the default card number is 1
#
# Changelog
# 2005-01-12: added $! to terminate ntsc-cc and channel-timestamp
# 2005-04-15: added $DEV input parameter to handle multiple tv cards
# 2005-04-23: added aumix -d /dev/mixer1 -1 R for sound off the saa
# 2005-05-13: added mixer device number
# 2005-05-16: new directories are created with 775
# 2005-05-22: added busy test
# 2005-10-07: use zvbi-ntsc-cc, soon in libzvbi 0.2.17
# 2006-02-15: removed colon from filename (FIL=)
# 2006-08-18: added drive assignment routine (checks for space)
# 2006-09-04: switched from oss to alsa (2.6.17 kernel)
# 2006-09-14: check /dev/vbi$DEV instead of /dev/dsp$DEV in busy loop
# (you could use /dev/video$DEV)
# 2006-09-20: added some messages at the end, using 24-hour time
# 2006-09-24: added XDS information to closed captioning
#
# ***************************************************************************

# First some checks triggered by manual mode

if [ "$1" = "" ] ; then
echo "Use news <channel number> <recording time in minutes>";
echo "Please give a channel! Valid channels are 2, 4, 5, 7, 9, 11, 13, and 28.";
exit
fi

if [ "$2" = "" ] ; then
echo "Use news <channel number> <recording time in minutes>";
echo "Please give a recording length in minutes!";
exit
fi

if [ "$3" = "" ] ; then
echo "Use news <number> <duration> <title>";
echo "Please give a title to the recording!";
exit
fi

# Define the video and VBI (vertical blanking interval) device to use
# Default is /dev/video1 and /dev/vbi1
if [ "$4" = "" ] ;
then DEV=1
else DEV=$4
fi

# Define variable DRV to contain the first tv drive with more than 1% free
for i in $(df | cut -d'/' -f4 | grep tv | sort); do
if [ "$(df /$i | grep $i | cut -b 52-54)" -lt 99 ]
then DRV=$i
echo "Using drive" $DRV "with" "$(df -h /$i | grep $i | cut -b 35-37)GB free"
break
fi
done

# Define variable DIR to contain nested directories for
# yyyy, yyyy-mm, and yyyy-mm-dd (today's date)
DIR=/$DRV/$(date +%Y)/$(date +%Y-%m)/$(date +%F)

# Create the directory (and any missing parents) if needed
if test ! -d $DIR
then mkdir -p -m 775 $DIR
fi

# Strip the comma, if any, from the channel name
CH=${1%,*}

# Set the channel (current user needs X11 access)
# You can also set this in mencoder with tv://$CH or channel=$CH
v4lctl -c /dev/video$DEV setchannel $CH

# Convert channel number to name for the base file name
case $CH in
2) CH=KCBS;;
4) CH=KNBC;;
5) CH=KTLA-WB;;
7) CH=KABC;;
9) CH=KCAL;;
11) CH=KTTV-FOX;;
13) CH=KCOP-UPN;;
28) CH=KCET;;
esac

# Strip the {min,|min|,} if it's there, from the duration
TIM=${2%m*}; TIM=${TIM%,*}

# Strip the comma, if any, from the title, and convert spaces to underscores
TIT=_`echo ${3%,*} | sed -e "s/ /_/g"`

# Define the file name (escape underscore before $) and print it to screen
FIL=$(date +%F_%H%M)\_$CH$TIT; echo Preparing to record $FIL

# Check if the capture device is busy
BUSY="Capture card $DEV is busy -- will try for another five minutes \n"
START=$(date +%s); TARGET=$[$START + $[5*60]]

while [ "$(sudo lsof /dev/vbi$DEV)" != "" ]; do
if [ $TARGET -gt $(date +%s) ]
then echo -ne $BUSY
sleep 5; BUSY=""
else echo "Recording of $FIL aborted -- capture card $DEV is not available"
exit
fi
done

# Convert minutes to seconds and adjust down five seconds for the hardware to reset
TIM=$[$[TIM*60]-5]

# Adjust the duration down by the delay added by the busy check, exit if no time left
TIM=$[TIM-$[$(date +%s) -$START]]; if [ $TIM -lt 1 ]; then exit; fi

# Start the timestamp script and background
channel-timestamp $CH $TIT $DIR $FIL &

# Get the PID for the timestamper
TMSP=$!

# Start cc capture and background the process
zvbi-ntsc-cc -d /dev/vbi$DEV -cpx >> $DIR/$FIL.txt &

# Get the PID for the closed captioning
NTSC=$!

# Restore default sound sttings and open up the sound channel on the capture card
/usr/sbin/alsactl restore $DEV

# Set any additional values (none currently needed)
#v4lctl -c /dev/video0 color "50%"

# Record the footage (note this assumes direct audio)

# Use this to control the bitrate -- default is 800
#lavc -lavcopts vbitrate=1800 -oac mp3lame -lameopts cbr:br=128 -endpos $TIM -o \

echo "Initiating recording of $FIL from channel $1"
echo "on capture card $DEV, at $(date +%T), duration $TIM seconds"

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=hw.$DEV:alsa:input=0:amode=1:normid=4 -ffourcc DIVX -ovc \
lavc -oac mp3lame -lameopts cbr:br=128 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

# Stamp the file with receipts to verify capture success
echo -e "\n"
ls -l $DIR/$FIL.*
echo -e "\nCompleted capture on $(date +%A\ %d\ %B\ %Y) at $(date +%T)"
echo -e "Video and audio file size" $(ls -sh $DIR/$FIL.avi | cut -d' ' -f1)
echo -e "Closed captioning file size" $(ls -sh $DIR/$FIL.txt | cut -d' ' -f1) "\n"

# Terminate the closed captioning and the timestamper
kill $NTSC $TMSP

# EOF

</pre>

The only part of the script that gave me trouble over a prolonged period was the transition between recordings. Sometimes it takes the kernel several seconds to activate a card, and if the recording length doesn't compensate down, the next scheduled recording bumps into a busy device. However, this problem appears to have been fully solved in the current busy script, which waits for up to five minutes and shortens the recording time by the time waited.

I also tended to lose some programs when a drive was full, since I often missed the exact moment, so I've added some lines to look for a drive with space. I was filling drives at the rate of 4GB a day and had room for four drives, so it would take a year to fill a set of 400GB drives.

===Variant: capture to H.264 using alsa===

If you want to capture to H.264 instead, and use the new [[saa7134-alsa]] module for getting sound, you can use this (and drop aumix from the script, as it doesn't appear to understand alsa's device notation):

<pre>
mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:alsa:adevice=hw.$DEV:input=0:amode=1:normid=4:width=576:height=480 \
-ovc x264 -x264encopts bitrate=500:bframes=2:subq=2:me=2:frameref=2 \
-oac mp3lame -lameopts cbr:br=64 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null
</pre>

===Time-stamping script===

The main script calls this little routine for timestamping the closed captioning files. this is useful only if you want to set up a searchable database of text.

<pre>
#!/bin/bash
#
# /usr/local/bin/channel-timestamp
#
# This shell script is used to add timestamps to closed captioning
# It is called by the main recording script, /usr/local/bin/channel.
#
# Add -xv to the top line to get verbose messages
#
# Changelog:
# 2005-01-12: The parent script now handles child process terminations
# 2005-01-13: Timestamps could use XDS data -- start with the date and
# include title (not implemented)
#
# *****************************************************************

# Write the first timestamp
echo $(date +%F_%H:%M:%S)_$1$2 >> $3/$4.txt

# Write a timestamp every ten seconds
while true
do
sleep 10
echo $(date +%F_%H:%M:%S)_$1$2 >> $3/$4.txt
done

# EOF

</pre>

===Crontabs===

While programs can be captured manually using the channel script, I use [http://www.linuxhelp.net/guides/cron/ cron] for scheduled recordings.

Here are some examples of crontab usage:

<pre>

# Folders to search for program files.
PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Email output to specified account.
MAILTO=tna
# KCAL 9 News at 9pm
0 21 * * 6 channel 9, 60min, "News at 9pm", 1
# KNBC 4 Meet the Press
0 8 * * 7 channel 4, 60min, "Meet the Press", 2
# KABC 7 World News Tonight
30 17 * * 7 channel 7, 30min, "World News Tonight", 1
# KCBS 2 60 Minutes
0 19 * * 7 channel 2, 60min, "60 Minutes", 1
# Fox 11 Morning News at 6 AM/ Good Day LA
0 6 * * 1,2,3,4,5 channel 11, 60min, "Morning News at 6", 1
# KCET 28 BBC World News
30 5 * * 1,2,3,4,5 channel 28, 30min, "BBC World News", 3

</pre>

You can edit crontab with kcron or with the "crontab -e" command. It's also possible to use scripts to add jobs:

crontab -l >> newjob | crontab newjob

If you have a complex crontab you don't want to lose, back it up with "crontab -l > crontab-$(date +%F_%H:%M)".

V4L IEEE1394 devices

2008-02-15T05:33:14Z

Liontooth: "Firewire" is strictly speaking Apple's badge on the ieee1394 standard

The [[Development:_Video4Linux_APIs|V4L API]] in itself does not support any [http://www.linux1394.org ieee1394] (Firewire) devices. However, in the case of some devices, V4L applications can obtain access to video via ieee1394, using either a [[Loopback|loopback]] or LD_PRELOAD method.

== via Loopback ==
* V4L with ieee1394 camcorders:
** using DV4Linux's [http://dv4l.berlios.de dv4l]
** using [http://www.kinodv.org/ dvgrab] and [http://www.lavrsen.dk/twiki/bin/view/Motion/Dv2Vloopback dv2vloopback]
* V4L with ieee1394 cameras:
** using [http://damien.douxchamps.net/ieee1394/coriander/index.php Coriander]

== via LD_PRELOAD==
* V4L with ieee1394 camcorders:
** using DV4Linux's [http://dv4l.berlios.de dv4lstart]

V4L capturing

2008-01-12T14:09:46Z

Liontooth:

==TV Recording applications==

* [http://dvr.sourceforge.net DVR] -- Digital Video Recorder for Linux
* [http://ffmpeg.sourceforge.net/index.php ffmpeg] (see also below)
** [http://man.cx/ffmpeg(1) man page] (man.cx)
* [http://fftv.sourceforge.net fftv]
* [[gstreamer]]
* [http://xawdecode.sourceforge.net/ XdTV] -- XdTV is a software that allows you to watch record & stream TV
* [http://freevo.sourceforge.net Freevo] -- open-source digital video jukebox
* [[mencoder]]
** [http://linuxreviews.org/man/mencoder/ man page] (''Linux Reviews'')
** [[channel script |the channel scripts]]
** [[capture script |the capture script]]
* [[MythTV]] -- a Personal Video Recorder project
* [[streamer]]
* [[transcode]]
* [http://paginas.terra.com.br/informatica/gleicon/video4linux/videodog.html videodog]
* [[vlc]]

==Other frame grabbers==

* See [[webcams]]

==Common configuration and control commands==

1. [[v4l2ucp]] -- universal control panel for v4l2 (available for Debian from [http://debian.video.free.fr/ Marillat])

2. Command-line control the TV card

:a. v4lctl is a part of the xawtv package
:* v4lctl -c /dev/video0 list
:* v4lctl -c /dev/video0 bright "60%"
:* v4lctl -c /dev/video0 contrast "55%"

:b. [http://www.vanheusden.com/dov4l/ dov4l]
:* Console tool that sets the parameters of a Video4Linux-device
:* You can set picture size, brightness, contrast, tuner frequency, and so on.
:* You can also retrieve a complete list of all current settings.

3. Capture the stream
:* videodog:
:: ''Usage:''
:: videodog -x 640 -y 480 -w 3 -b 1 -c 65535 -m PAL -q -d /dev/video0 -j -f /var/www/webcam.jpg
:* webcam:
:: This useful tool supports continuously moving (ftp or scp - ssh copy) of jpeg output to remote server. Also allows put in additional text (date time, location), rotating of image.
:: ''Usage:''
:: webcam /etc/webcamrc
:: See [[webcams]] for model and driver details

==Capture from composite or S-video==

ffmpeg -async 12 -vd /dev/video -ad /dev/dsp -f avi -r 25 -s 720x576 -croptop 8 -cropbottom 8 -cropleft 8 \
-cropright 8 -sameq -aspect 4:3 -acodec mp2 -ac 2 -ab 224k -ar 48000 -y -t 04:30:00 outfile.avi

:*-async 12 (helps eliminate problems with audio/video syncronization)
:*v4lctl setattr vcr_hack (needed for bttv cards - can also be set in /etc/modprobe.conf)
:*crop values result in far better quality/file size

==Compression formats==

:*[http://wiki.multimedia.cx Multimediawiki]
:*[http://www.fourcc.org/ Fourcc site]
:*[http://developers.videolan.org/x264.html x264] -- GPL H.264 encoder
:**Offers best quality/bitrate efficiency, but a fast CPU for playback/recording is recommended
:**[http://mirror01.x264.nl/x264/changelog.txt x264 Changelog]
:**[http://www.avidemux.org/admWiki/index.php?title=H264 Options] overview in Avidemux
:*[http://www.xvid.org xvid] -- free mpeg4 codec

==Live x264 capture comparison==

The x264 encoder is now of such a high quality that it is possible to compress live tv on the fly with good results. So far transcode is the only solution that delivers on all counts: good audio/video synchronization, small file size, efficient encoding (full size and high quality without dropped frames), and a resulting file that streams with VLC. These results, however, may vary locally; the following is a status report from late March 2006 on a Debian amd64 sid with Marillat's multimedia packages and a dual-core or dual amd64 CPU.

<br>

<table border="10" cellpadding="5" width="70%" cellspacing="3" frame="hsides" rules="all">

<tr>
<th>application</th>
<th>a/v sync</th>
<th>efficiency</th>
<th>file size</th>
<th>streaming</th>
</tr>

<tr>
<td>ffmpeg</td>
<td>middling</td>
<td>good</td>
<td>small</td>
<td>yes</td>
</tr>

<tr>
<td>mencoder</td>
<td>great</td>
<td>poor</td>
<td>smaller</td>
<td>no</td>
</tr>

<tr>
<td>transcode</td>
<td>good</td>
<td>great</td>
<td>variable</td>
<td>yes</td>
</tr>

<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>

</table>

<br>

<b>ffmpeg</b>

ffmpeg -threads 2 -vd /dev/video$DEV -r 29.97 -b 800 -s 640x480 -vcodec h264 -qmax 51 \
-me epzs -deinterlace -g 300 -async 1 -ac 2 -acodec mp3 -ab 96 -ar 32000 \
-ad /dev/dsp$DEV -t $TIM -f avi -y $DIR/$FIL.avi

* a/v sync drifts a bit -- not reliable
* encoding efficiency is high, but frames are dropped silently

<b>mencoder</b>

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=/dev/dsp$DEV:input=0:amode=1:normid=4:width=512:height=384 \
-ovc x264 -x264encopts threads=2:bitrate=800:subq=2:me=2:frameref=4:8x8dct \
-oac mp3lame -lameopts cbr:br=96 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

* creates files that don't stream correctly in VLC -- we've not got to the bottom of this
* encoding efficiency is somewhat below ffmpeg and transcode -- cannot capture to full 640x480 size without dropping frames
* superior to the others in its ability to accept a much fuller set of x264 encoding parameters

<b>transcode</b>

transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
-i /dev/video$DEV -p /dev/dsp$DEV -y ffmpeg -F h264 -c 00:$TIM \
-g 640x480 -f 29.970,4 -u 1024,2 -w 800 -b 96 -Q 5 -e 32000,16,2 \
--lame_preset medium -o $DIR/$FIL.avi

* after adding the resync parameters, the sync problem, previously severe, appears to be solved!
* does a great job keeping up with frames -- full-size capture with no drops -- though I'm still wondering if it might be dropping frames silently
* file sizes are highly variable and are poorly controlled by the -w video bitrate switch
* on a single CPU, the audio track is confused and overlapping; on a dual-core or dual CPU, the result is good
* to run two threads, see [[Transcode]].

A change was made to the x264 repository on 1 August 2006 that allows the switch --threads=auto to detect the number of CPUs.

<b>General</b>

File size is in theory a simple function of audio and video bitrates. In practice, ffmpeg and mencoder produce files according to bitrate settings, while transcode is all over the map -- in a small sample of ten, an hour at "-w 500" ranged from a small 377MB all the way up to 684MB, and "-w 800" from 407MB to 754MB. Quality may also vary; currently not assessed.

See also [[Talk:TV_Recording |Discussion]].

V4L capturing

2008-01-11T16:17:31Z

Liontooth:

==TV Recording applications==

* [http://dvr.sourceforge.net DVR] -- Digital Video Recorder for Linux
* [http://ffmpeg.sourceforge.net/index.php ffmpeg] (see also below)
* [http://fftv.sourceforge.net fftv]
* [[gstreamer]]
* [http://xawdecode.sourceforge.net/ XdTV] -- XdTV is a software that allows you to watch record & stream TV
* [http://freevo.sourceforge.net Freevo] -- open-source digital video jukebox
* [[mencoder]]
** [http://linuxreviews.org/man/mencoder/ man page] (''Linux Reviews'')
** [[channel script |the channel scripts]]
** [[capture script |the capture script]]
* [[MythTV]] -- a Personal Video Recorder project
* [[streamer]]
* [[transcode]]
* [http://paginas.terra.com.br/informatica/gleicon/video4linux/videodog.html videodog]
* [[vlc]]

==Other frame grabbers==

* See [[webcams]]

==Common configuration and control commands==

1. [[v4l2ucp]] -- universal control panel for v4l2 (available for Debian from [http://debian.video.free.fr/ Marillat])

2. Command-line control the TV card

:a. v4lctl is a part of the xawtv package
:* v4lctl -c /dev/video0 list
:* v4lctl -c /dev/video0 bright "60%"
:* v4lctl -c /dev/video0 contrast "55%"

:b. [http://www.vanheusden.com/dov4l/ dov4l]
:* Console tool that sets the parameters of a Video4Linux-device
:* You can set picture size, brightness, contrast, tuner frequency, and so on.
:* You can also retrieve a complete list of all current settings.

3. Capture the stream
:* videodog:
:: ''Usage:''
:: videodog -x 640 -y 480 -w 3 -b 1 -c 65535 -m PAL -q -d /dev/video0 -j -f /var/www/webcam.jpg
:* webcam:
:: This useful tool supports continuously moving (ftp or scp - ssh copy) of jpeg output to remote server. Also allows put in additional text (date time, location), rotating of image.
:: ''Usage:''
:: webcam /etc/webcamrc
:: See [[webcams]] for model and driver details

==Capture from composite or S-video==

ffmpeg -async 12 -vd /dev/video -ad /dev/dsp -f avi -r 25 -s 720x576 -croptop 8 -cropbottom 8 -cropleft 8 \
-cropright 8 -sameq -aspect 4:3 -acodec mp2 -ac 2 -ab 224k -ar 48000 -y -t 04:30:00 outfile.avi

:*-async 12 (helps eliminate problems with audio/video syncronization)
:*v4lctl setattr vcr_hack (needed for bttv cards - can also be set in /etc/modprobe.conf)
:*crop values result in far better quality/file size

==Compression formats==

:*[http://wiki.multimedia.cx Multimediawiki]
:*[http://www.fourcc.org/ Fourcc site]
:*[http://developers.videolan.org/x264.html x264] -- GPL H.264 encoder
:**Offers best quality/bitrate efficiency, but a fast CPU for playback/recording is recommended
:**[http://mirror01.x264.nl/x264/changelog.txt x264 Changelog]
:**[http://www.avidemux.org/admWiki/index.php?title=H264 Options] overview in Avidemux
:*[http://www.xvid.org xvid] -- free mpeg4 codec

==Live x264 capture comparison==

The x264 encoder is now of such a high quality that it is possible to compress live tv on the fly with good results. So far transcode is the only solution that delivers on all counts: good audio/video synchronization, small file size, efficient encoding (full size and high quality without dropped frames), and a resulting file that streams with VLC. These results, however, may vary locally; the following is a status report from late March 2006 on a Debian amd64 sid with Marillat's multimedia packages and a dual-core or dual amd64 CPU.

<br>

<table border="10" cellpadding="5" width="70%" cellspacing="3" frame="hsides" rules="all">

<tr>
<th>application</th>
<th>a/v sync</th>
<th>efficiency</th>
<th>file size</th>
<th>streaming</th>
</tr>

<tr>
<td>ffmpeg</td>
<td>middling</td>
<td>good</td>
<td>small</td>
<td>yes</td>
</tr>

<tr>
<td>mencoder</td>
<td>great</td>
<td>poor</td>
<td>smaller</td>
<td>no</td>
</tr>

<tr>
<td>transcode</td>
<td>good</td>
<td>great</td>
<td>variable</td>
<td>yes</td>
</tr>

<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>

</table>

<br>

<b>ffmpeg</b>

ffmpeg -threads 2 -vd /dev/video$DEV -r 29.97 -b 800 -s 640x480 -vcodec h264 -qmax 51 \
-me epzs -deinterlace -g 300 -async 1 -ac 2 -acodec mp3 -ab 96 -ar 32000 \
-ad /dev/dsp$DEV -t $TIM -f avi -y $DIR/$FIL.avi

* a/v sync drifts a bit -- not reliable
* encoding efficiency is high, but frames are dropped silently

<b>mencoder</b>

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=/dev/dsp$DEV:input=0:amode=1:normid=4:width=512:height=384 \
-ovc x264 -x264encopts threads=2:bitrate=800:subq=2:me=2:frameref=4:8x8dct \
-oac mp3lame -lameopts cbr:br=96 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

* creates files that don't stream correctly in VLC -- we've not got to the bottom of this
* encoding efficiency is somewhat below ffmpeg and transcode -- cannot capture to full 640x480 size without dropping frames
* superior to the others in its ability to accept a much fuller set of x264 encoding parameters

<b>transcode</b>

transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
-i /dev/video$DEV -p /dev/dsp$DEV -y ffmpeg -F h264 -c 00:$TIM \
-g 640x480 -f 29.970,4 -u 1024,2 -w 800 -b 96 -Q 5 -e 32000,16,2 \
--lame_preset medium -o $DIR/$FIL.avi

* after adding the resync parameters, the sync problem, previously severe, appears to be solved!
* does a great job keeping up with frames -- full-size capture with no drops -- though I'm still wondering if it might be dropping frames silently
* file sizes are highly variable and are poorly controlled by the -w video bitrate switch
* on a single CPU, the audio track is confused and overlapping; on a dual-core or dual CPU, the result is good
* to run two threads, see [[Transcode]].

A change was made to the x264 repository on 1 August 2006 that allows the switch --threads=auto to detect the number of CPUs.

<b>General</b>

File size is in theory a simple function of audio and video bitrates. In practice, ffmpeg and mencoder produce files according to bitrate settings, while transcode is all over the map -- in a small sample of ten, an hour at "-w 500" ranged from a small 377MB all the way up to 684MB, and "-w 800" from 407MB to 754MB. Quality may also vary; currently not assessed.

See also [[Talk:TV_Recording |Discussion]].

V4L capturing

2008-01-11T16:15:13Z

Liontooth:

==TV Recording applications==

* [http://dvr.sourceforge.net DVR] -- Digital Video Recorder for Linux
* [http://ffmpeg.sourceforge.net/index.php ffmpeg] (see also below)
** [http://linuxreviews.org/man/ffmpeg/ man page] (''Linux Reviews'')
* [http://fftv.sourceforge.net fftv]
* [[gstreamer]]
* [http://xawdecode.sourceforge.net/ XdTV] -- XdTV is a software that allows you to watch record & stream TV
* [http://freevo.sourceforge.net Freevo] -- open-source digital video jukebox
* [[mencoder]]
** [http://linuxreviews.org/man/mencoder/ man page] (''Linux Reviews'')
** [[channel script |the channel scripts]]
** [[capture script |the capture script]]
* [[MythTV]] -- a Personal Video Recorder project
* [[streamer]]
* [[transcode]]
* [http://paginas.terra.com.br/informatica/gleicon/video4linux/videodog.html videodog]
* [[vlc]]

==Other frame grabbers==

* See [[webcams]]

==Common configuration and control commands==

1. [[v4l2ucp]] -- universal control panel for v4l2 (available for Debian from [http://debian.video.free.fr/ Marillat])

2. Command-line control the TV card

:a. v4lctl is a part of the xawtv package
:* v4lctl -c /dev/video0 list
:* v4lctl -c /dev/video0 bright "60%"
:* v4lctl -c /dev/video0 contrast "55%"

:b. [http://www.vanheusden.com/dov4l/ dov4l]
:* Console tool that sets the parameters of a Video4Linux-device
:* You can set picture size, brightness, contrast, tuner frequency, and so on.
:* You can also retrieve a complete list of all current settings.

3. Capture the stream
:* videodog:
:: ''Usage:''
:: videodog -x 640 -y 480 -w 3 -b 1 -c 65535 -m PAL -q -d /dev/video0 -j -f /var/www/webcam.jpg
:* webcam:
:: This useful tool supports continuously moving (ftp or scp - ssh copy) of jpeg output to remote server. Also allows put in additional text (date time, location), rotating of image.
:: ''Usage:''
:: webcam /etc/webcamrc
:: See [[webcams]] for model and driver details

==Capture from composite or S-video==

ffmpeg -async 12 -vd /dev/video -ad /dev/dsp -f avi -r 25 -s 720x576 -croptop 8 -cropbottom 8 -cropleft 8 \
-cropright 8 -sameq -aspect 4:3 -acodec mp2 -ac 2 -ab 224k -ar 48000 -y -t 04:30:00 outfile.avi

:*-async 12 (helps eliminate problems with audio/video syncronization)
:*v4lctl setattr vcr_hack (needed for bttv cards - can also be set in /etc/modprobe.conf)
:*crop values result in far better quality/file size

==Compression formats==

:*[http://wiki.multimedia.cx Multimediawiki]
:*[http://www.fourcc.org/ Fourcc site]
:*[http://developers.videolan.org/x264.html x264] -- GPL H.264 encoder
:**Offers best quality/bitrate efficiency, but a fast CPU for playback/recording is recommended
:**[http://mirror01.x264.nl/x264/changelog.txt x264 Changelog]
:**[http://www.avidemux.org/admWiki/index.php?title=H264 Options] overview in Avidemux
:*[http://www.xvid.org xvid] -- free mpeg4 codec

==Live x264 capture comparison==

The x264 encoder is now of such a high quality that it is possible to compress live tv on the fly with good results. So far transcode is the only solution that delivers on all counts: good audio/video synchronization, small file size, efficient encoding (full size and high quality without dropped frames), and a resulting file that streams with VLC. These results, however, may vary locally; the following is a status report from late March 2006 on a Debian amd64 sid with Marillat's multimedia packages and a dual-core or dual amd64 CPU.

<br>

<table border="10" cellpadding="5" width="70%" cellspacing="3" frame="hsides" rules="all">

<tr>
<th>application</th>
<th>a/v sync</th>
<th>efficiency</th>
<th>file size</th>
<th>streaming</th>
</tr>

<tr>
<td>ffmpeg</td>
<td>middling</td>
<td>good</td>
<td>small</td>
<td>yes</td>
</tr>

<tr>
<td>mencoder</td>
<td>great</td>
<td>poor</td>
<td>smaller</td>
<td>no</td>
</tr>

<tr>
<td>transcode</td>
<td>good</td>
<td>great</td>
<td>variable</td>
<td>yes</td>
</tr>

<tr>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>

</table>

<br>

<b>ffmpeg</b>

ffmpeg -threads 2 -vd /dev/video$DEV -r 29.97 -b 800 -s 640x480 -vcodec h264 -qmax 51 \
-me epzs -deinterlace -g 300 -async 1 -ac 2 -acodec mp3 -ab 96 -ar 32000 \
-ad /dev/dsp$DEV -t $TIM -f avi -y $DIR/$FIL.avi

* a/v sync drifts a bit -- not reliable
* encoding efficiency is high, but frames are dropped silently

<b>mencoder</b>

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=/dev/dsp$DEV:input=0:amode=1:normid=4:width=512:height=384 \
-ovc x264 -x264encopts threads=2:bitrate=800:subq=2:me=2:frameref=4:8x8dct \
-oac mp3lame -lameopts cbr:br=96 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

* creates files that don't stream correctly in VLC -- we've not got to the bottom of this
* encoding efficiency is somewhat below ffmpeg and transcode -- cannot capture to full 640x480 size without dropping frames
* superior to the others in its ability to accept a much fuller set of x264 encoding parameters

<b>transcode</b>

transcode -x v4l2=resync_margin=1:resync_interval=250,v4l2 -M 2 \
-i /dev/video$DEV -p /dev/dsp$DEV -y ffmpeg -F h264 -c 00:$TIM \
-g 640x480 -f 29.970,4 -u 1024,2 -w 800 -b 96 -Q 5 -e 32000,16,2 \
--lame_preset medium -o $DIR/$FIL.avi

* after adding the resync parameters, the sync problem, previously severe, appears to be solved!
* does a great job keeping up with frames -- full-size capture with no drops -- though I'm still wondering if it might be dropping frames silently
* file sizes are highly variable and are poorly controlled by the -w video bitrate switch
* on a single CPU, the audio track is confused and overlapping; on a dual-core or dual CPU, the result is good
* to run two threads, see [[Transcode]].

A change was made to the x264 repository on 1 August 2006 that allows the switch --threads=auto to detect the number of CPUs.

<b>General</b>

File size is in theory a simple function of audio and video bitrates. In practice, ffmpeg and mencoder produce files according to bitrate settings, while transcode is all over the map -- in a small sample of ten, an hour at "-w 500" ranged from a small 377MB all the way up to 684MB, and "-w 800" from 407MB to 754MB. Quality may also vary; currently not assessed.

See also [[Talk:TV_Recording |Discussion]].

LifeView FlyVideo3000FM NTSC

2007-12-12T16:11:28Z

Liontooth: /* Recording with mencoder */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. I've worked with up to five cards in one computer, though you need a powerful CPU to keep up with the data flow.

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[LifeView FlyVideo3000 PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot. With 2.6.19, I switched to tuner 95.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DX50 -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with medium-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for internal audio input (directly via the PCI bus), you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[LifeView FlyTV Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].

==External Links==
* [http://www.lifeview.com/usa/html/products/PCITV/FlyVideo3000-w1.htm LifeView product page]

Webcam Devices

2007-09-23T00:16:50Z

Liontooth: /* Applications */

==Applications==

* [http://tldp.org/HOWTO/Webcam-HOWTO/index.html The Webcam HowTo]
** [http://tldp.org/HOWTO/Webcam-HOWTO/framegrabbers.html framegrabbing applications]
* [http://www.ekiga.org Ekiga] -- Ekiga is a free Voice over IP phone allowing you to do free calls over the Internet. Ekiga is the first Open Source application to support both H.323 and SIP, as well as audio and video. Ekiga was formerly known as GnomeMeeting.
* [http://www.firestorm.cx/fswebcam/ fswebcam] -- fswebcam is a neat and simple webcam app for Linux. It captures images from a V4L1/V4L2 compatible device or file, averages them to reduce noise and draws a caption using the GD Graphics Library which also handles compressing the image to PNG or JPEG. The resulting image is saved to a file or sent to stdio where it can be piped to something like ncftpput or scp.
* [http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome motion] -- motion-detection using a webcam (on [http://motion.sourceforge.net sourceforge])
* [http://www.stolk.org/sonic-snap/ sonic-snap] -- webcam application specifically suited for the Sonix sn9c10x chip
* [http://www.litech.org/spook spook] -- capture live video and audio and stream it over an IP network
* [http://julien.danjou.info/telak.html telak] -- display remote or local pictures on your desktop
* [http://vgrabbj.gecius.de/ vgrabbj] -- grabs a image from a camera and puts it in jpg/png format
* [http://www.linux-projects.org/ Videoview & Device Debugger] -- applications suited for some drivers present in the Linux kernel. Videoview supports the USB Video Class standard.
* [http://linux.bytesex.org/xawtv webcam] -- captures images and uploads them to a Web-Server via ftp or ssh in a endless loop
* [http://naaa.de/uvc_streamer.htm UVC-streamer] -- Grabs JPEGs from Linux-UVC compatible cameras and serves them as M-JPEG stream. It is very ressource friendly, most of the time you do not even recognize it in <tt>top</tt>. It allows to Pan/Tilt the camera, the upcoming second version (''mjpg-streamer'') will also support motion detection and plugins.

==Resources==
* [http://www.exploits.org/v4l/ Video for Linux resources] -- see Video: Security / Webcams / Monitoring
* For USB webcams, see also [http://www.qbik.ch/usb/devices/search_res.php?pattern=video&submit=Search%21 video devices] in the [http://www.qbik.ch/usb/devices/index.php USB device overview database]

==UVC webcams==

Do you have USB 2.0 controllers on your notebook and desktop? If so, you could benefit from higher resolutions with the Logitech Quickam for Notebooks Pro, Quickcam Fusion and Quickcam Orbit MP. All those webcams are 1.3MP devices and are supported by the [http://linux-uvc.berlios.de/ linux-uvc] driver. Note that the Quickcam for Notebooks Deluxe doesn't fall in that category; it's supported by the [http://mxhaard.free.fr/ spca5xx] driver.

Those 3 webcams also work in USB 1.1 mode, but are then limited to 640x480. In that case, you could go for the Quickcam Pro 5000, which is a 640x480 device supported by the linux-uvc driver.

UVC webcams are well supported, but you must be aware of a few issues.

* The linux-uvc driver is V4L2-only. This means applications which support V4L1 only will not work. V4L1 is officially deprecated, and have been removed from the kernel recently, so most drivers have or will switch to V4L2 anyway.

* The 4 webcams mentioned above compress images in MJPEG for resolutions up to 960x720. This means that applications must be able to decompress MJPEG streams to use the webcam at lower resolutions. Ekiga supports MJPEG compression.

==Webcam drivers==
(alphabetize by driver)

Many of these are out-of-tree kernel drivers.

* [http://webcam.sourceforge.net/ cpia] -- first generation of STM's Color Processor Interface (ASIC) [[Cpia]]
**Included in mainline kernel
**Supports a large number of USB devices by Aiptek, Creative, Digicom, Dynalink, Ezonics, Intel, Microtek, Pace, SuperCam, TCE, Terracom, Trust, Utobia, ZoomCam
**Supports some parallel port devices by Creative, CVideo, CU-SeeMe, Digicom, and ZoomCam
* [[cpia2]] -- second generation of STM's Color Processor Interface (ASIC)
**Included in mainline kernel from 2.6.18
**Supports the [[QX5 USB microscope]], the Swann Versacam MINI webcam, and other devices using the second generation of STM's Color Processor Interface (ASIC)
* [[em2880]]
**Supports the [http://videologyinc.com/cameras/ccd-board-camera-20K14XUSB.htm Videology 20K14XUSB webcam]
**Included in mainline kernel from 2.6.18 (em28xx)
* [http://www.linux-projects.org et61x251]
**Supports Etoms ET61X151 or ET61X251-based USB cameras
**Included in mainline kernel
* [http://icm532.sourceforge.net/ icm532]
* [http://linux-uvc.berlios.de/ linux-uvc] -- the USB Video Class Linux device driver
**Not included in the kernel (as of 2.6.18), but several distros have ready packages
**Supports several USB2.0 Logitech Quickcams, such as the Orbit MP, the Pro for Notebooks, the Pro 5000, the Dell Notebook, and the Cisco VT Camera II
* [http://popies.net/meye/ meye] -- the Sony Vaio PictureBook Motion Eye Camera Driver
**Included in 2.4 and 2.6 kernels -- see [[meye |documentation]]
**Supports the second version of the MotionEye camera (PCI vendor/device 0x136b/0xff01)
**A driver for the third version is being written, see r-engine below
* [http://nw802.sourceforge.net/ nw802]
* [http://alpha.dyndns.org/ov511/ ov511]
* [http://www.saillard.org/linux/pwc/ pwc] -- the new driver
**Available in the latest kernels
**Supports Philips USB webcams
**[http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome PWC wiki]
**[http://www.smcc.demon.nl/webcam/ Discontinued version]
* [http://qce-ga.sourceforge.net/ qce-ga/qc-usb]
**Kernel module package available in
***Debian stable ([http://packages.debian.org/stable/misc/qce-source qce-source])
***Deban testing and unstable ([http://packages.debian.org/unstable/misc/qc-usb-source qc-usb-source], see also [http://git.debian.org/?p=collab-maint/qc-usb.git;a=summary git repository])
**Supports Logitech Quickcam Express, LegoCam, Dexxa Webcam, Labtec Webcam (old model), Logitech QuickCam Notebook (some models)
* [http://www.informatik.uni-oldenburg.de/%7Edelwi/quickcam/ quickcam]
* [http://r-engine.sourceforge.net/ r-engine]
**Aims to support Sony Vaio Picturebooks (model PCG-C1M* and newer, PCI vendor/device 0x10cf/0x2011)
* [http://members.brabant.chello.nl/%7Ej.vreeken/se401/ se401]
* [http://sqcam.sourceforge.net/ sqcam]
**Supports webcams based on the sq905 chip, such as Volcano DG640E, Nexxtech Micro Digital Camera, Umax (Yamada) Astranugget; may work with Mito DG640E, Mitek CD10, Mitek 30P, GTW Electronics/ ShuoYing, Industrial(ShenZhen)Co.,Ltd SY-2102, Condord Eye-Q Easy / Eye Q Easy Too, Che-ez Snap, Hercules DualPix, Argus DC-1512, DC-1510, Gear to go, Magpix B350, Jenoptik JD 350, Concord Eye-Q Easy, PockCam
* [http://www.linux-projects.org/ Sonix SN9C10x]
**Available in the latest kernels as sn9c102
**Supports webcams based on the sn9c102 chip, such as the Genius VideoCam NB
**Another driver was in development here [http://sonix.sourceforge.net/ sonix]
**[http://tgnard.free.fr/linux/ sn9c101] -- patch for Trust Spacec@m
* [http://mxhaard.free.fr/ spca5xx]
**Supports webcams based on Sunplus Sonix Transvision Z-star/Vimicro Conexant Etoms chips
**Supports webcams such as Aiptek Pencam and Digital Dream l'espion
**See the long [http://mxhaard.free.fr/spca5xx.html list of devices]
* [http://syntekdriver.sourceforge.net/ stk11xx]
**Aims to support Syntek DC-1125/1135 cams
* [http://gkall.hobby.nl stv680] -- SANE backend
* [http://stv0680-usb.sourceforge.net/ sty0680]
* [http://home.t-online.de/home/free-photons/tv8532.html tv8532]
* [http://linux-uvc.berlios.de/ uvcvideo]
**USB Video Class driver
* [http://www.linux-projects.org/ w9968cf] -- included in the kernel
**Supports Winbond W9967CF or W9968CF-based USB cameras
** [http://winbond-webcam.sourceforge.net/ w9967cf (obsolete)]
* [http://www.royale.zerezo.com/zr364xx/ zr364xx]
**Supports the webcam mode of cameras based on the ZR364xx chips from wendors like Aiptek, Concord, Creative, Genius, Maxell, Fujifilm, Ricoh, Pentacon, Mustek, Konica, Umax etc.
* [http://www.linux-projects.org zc0301] -- included in the kernel
**Supports Z-Start/Vimicro ZC0301-based USB cameras
* [http://zc0302.sourceforge.net zc0302]

Text capture

2007-09-23T00:01:35Z

Liontooth: /* Testing */

==Introduction==

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

==Supported cards==

===bt8x8===

Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent support for text capture for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===saa713x===

Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent support for text capture under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

===ivtv===

For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the new [http://ivtvdriver.org ivtv] wiki.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the ivtv list suggests there is support for CC, VPS and WSS signals for the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi support to PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi support for pvr150/500.

The READMI.vbi in a current ivtv release has lots of details and attempts to improve it are going on.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently supports the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===DVB/DTV===

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] supports the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B] are not currently supported by the zvbi library. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Ditital Television Closed Captioning FAQ]for details.

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

Scott has recently (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for mplayer to display closed captioning; see the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for instructions.

===cx88===

The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

==Applications==

===alevt===

[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===gstreamer===

The application gstreamer has incorporated support for closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===mtt===

A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===nxtvepg===

The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===

The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===

tvtime has built-in support for closed captioning for [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===

[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===

The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.21 the V4L2 sliced API and ATSC are not yet supported.

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

===zvbi-ntsc-cc===

Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==Technical background==

===Analog television===

The vertical blanking interval (VBI) is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun
to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry
data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be
sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the [http://en.wikipedia.org/wiki/VBI vertical blanking interval] (vbi) on lines 17 through 20.

In North America, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the vertical blanking interval (NTSC standard).

===Digital television===

North American digital television (HDTV) uses the ATSC A/53 standard, cf. [http://www.atsc.org atsc.org]. Michael Schimek writes,

"It transmits CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD
caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have
enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc
it might suffice."

The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

===Displaying captured text===

To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===

Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.

Text capture

2007-09-22T23:51:50Z

Liontooth: Reverted edits by Liontooth (Talk); changed back to last version by Ariclone

==Introduction==

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

==Supported cards==

===bt8x8===

Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent support for text capture for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===saa713x===

Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent support for text capture under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

===ivtv===

For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the new [http://ivtvdriver.org ivtv] wiki.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the ivtv list suggests there is support for CC, VPS and WSS signals for the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi support to PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi support for pvr150/500.

The READMI.vbi in a current ivtv release has lots of details and attempts to improve it are going on.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently supports the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===DVB/DTV===

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] supports the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B] are not currently supported by the zvbi library. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Ditital Television Closed Captioning FAQ]for details.

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

Scott has recently (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for mplayer to display closed captioning; see the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for instructions.

===cx88===

The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

==Applications==

===alevt===

[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===gstreamer===

The application gstreamer has incorporated support for closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===mtt===

A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===nxtvepg===

The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===

The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===

tvtime has built-in support for closed captioning for [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===

[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===

The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.21 the V4L2 sliced API and ATSC are not yet supported.

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

===zvbi-ntsc-cc===

Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==Technical background==

===Analog television===

The vertical blanking interval (VBI) is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun
to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry
data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be
sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the [http://en.wikipedia.org/wiki/VBI vertical blanking interval] (vbi) on lines 17 through 20.

In North America, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the vertical blanking interval (NTSC standard).

===Digital television===

North American digital television (HDTV) uses the ATSC A/53 standard, cf. [http://www.atsc.org atsc.org]. Michael Schimek writes,

"It transmits CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD
caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have
enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc
it might suffice."

The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

===Displaying captured text===

To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===

Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes; cf. [[vbi images]]. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.

Text capture

2007-09-22T23:49:48Z

Liontooth: Reverted edits by Ariclone (Talk); changed back to last version by CityK

==Introduction==

[http://en.wikipedia.org/wiki/Teletext Teletext] is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.

In North America, [http://www.fcc.gov/cgb/dro/caption.html US federal law] requires [http://www.robson.org/capfaq/ closed captioning] of all non-exempt television programs starting in 2006. Some broadcasters are implementing [http://www.robson.org/capfaq/technical.html#XDS XDS], or Extended Data Services.

TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.

==Supported cards==

===bt8x8===

Cards based on the bt8x8 chip (cf. [[bttv devices (bt848, bt878)]] have excellent support for text capture for both PAL/SECAM and NTSC.

Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.

===saa713x===

Cards based on saa713x chips (cf. [[saa713x devices]]) have excellent support for text capture under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] from libzvbi 0.2.17, a drop-in replacement for xawtv's [[Text capture#ntsc-cc |ntsc-cc]].

The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.

===ivtv===

For details on [[Ivtv devices (cx23415, cx23416)| ivtv devices]], see the new [http://ivtvdriver.org ivtv] wiki.

This [http://www.gossamer-threads.com/lists/ivtv/devel/19383 exchange] on the ivtv list suggests there is support for CC, VPS and WSS signals for the PVR-350, but that hardware limitations prevent teletext.

Similarly, this [http://www.gossamer-threads.com/lists/ivtv/devel/16665?search_string=vbi;#16665 exchange] from January 2005 discusses an ongoing project adding vbi support to PVR-x50. Finally, in this [http://www.gossamer-threads.com/lists/ivtv/devel/19376 exchange] from April 2005, Chris Kennedy discusses vbi support for pvr150/500.

The READMI.vbi in a current ivtv release has lots of details and attempts to improve it are going on.

In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently supports the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.

===DVB/DTV===

The [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/WebHome zvbi library] supports the European standards [http://www.etsi.org ETSI EN 300 472] "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and [http://www.etsi.org ETSI EN 301 775] "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".

It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Documentation zvbi documentation]. The test/capture utility in the source tarball can demonstrate these capabilities.

The American standard [http://www.atsc.org ATSC A/53] "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard [http://global.ihs.com EIA 708-B] are not currently supported by the zvbi library. See the [http://en.wikipedia.org/wiki/EIA-708 EIA-708 Wikipedia entry] and [http://www.robson.org/capfaq/dtv.html Ditital Television Closed Captioning FAQ]for details.

However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."

Scott has recently (23 September 2005) written a [http://home.pacifier.com/~scowl/eia708.patch patch] for mplayer to display closed captioning; see the [http://www.pchdtv.com/forum/viewtopic.php?t=986&postdays=0&postorder=asc&highlight=closed+captioning&start=0 pchdtv forum] for instructions.

===cx88===

The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."

However, Tim sketched out exactly what needs to be done in this [http://marc.theaimsgroup.com/?l=linux-video&m=108518568124567&w=2 22 May 2004 e-mail].

As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a [http://www.spinics.net/lists/vfl/msg26029.html patch] being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.

In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. [http://nxtvepg.sourceforge.net/download.html#requirements system requirements].

==Applications==

===alevtv===

[http://www.goron.de/~froese/ AleVT] is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
[http://xawdecode.sourceforge.net/ XdTV] -- XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.

===gstreamer===

The application gstreamer has incorporated support for closed captioning (they also mention some tweaks for Canadian English and French television); see [http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/vbidec/ Freedesktop's repository].

===mtt===

A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.

===nxtvepg===

The [http://nxtvepg.sourceforge.net/index.html Nextview EPG decoder and browser] is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.

===ntsc-cc===

The application ntsc-cc handles closed captioning on [[bttv devices (bt848, bt878)]] only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.

For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.

An updated version of ntsc-cc is included in zvbi; see [[Text capture#zvbi-ntsc-cc |zvbi-ntsc-cc]] below.

===tvtime===

tvtime has built-in support for closed captioning for [[bttv devices (bt848, bt878)|bttv]] and [[saa713x devices|saa7134]] cards (also others?).

In early 2004, Kevin Ko wrote a [http://www.princeton.edu/~kko/tvtime/vbi_lock_0.2.patch patch with useful comments] to tvtime's vbidata.c; see [http://www.princeton.edu/~kko/tvtime/ his detailed account] and [https://sourceforge.net/tracker/?func=detail&atid=506989&aid=884449&group_id=64301 the tvtime bugreport].

===zapzilla===

[http://zapping.sourceforge.net Zapping] has a built-in teletext viewer called [http://zapping.sourceforge.net/cgi-bin/view/Main/Zapzilla Zapzilla].

In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.

===zvbi===

The [http://zapping.sourceforge.net/ZVBI zvbi library] offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.21 the V4L2 sliced API and ATSC are not yet supported.

Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.

===zvbi-ntsc-cc===

Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. [[saa713x devices]]).

Unlike [[Text capture#ntsc-cc |ntsc-cc]], zvbi-ntsc-cc does not require you to run another application for viewing or recording.

==Technical background==

===Analog television===

The vertical blanking interval (VBI) is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun
to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry
data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be
sent during this time period.

In the PAL standard, [http://en.wikipedia.org/wiki/Teletext Teletext] and Caption data is digitally encoded in the [http://en.wikipedia.org/wiki/VBI vertical blanking interval] (vbi) on lines 17 through 20.

In North America, [http://www.robson.org/capfaq/ closed captioning] uses line 21 of the vertical blanking interval (NTSC standard).

===Digital television===

North American digital television (HDTV) uses the ATSC A/53 standard, cf. [http://www.atsc.org atsc.org]. Michael Schimek writes,

"It transmits CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD
caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.

To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have
enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc
it might suffice."

The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.

===Displaying captured text===

To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.

===Testing===

Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.

For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on [http://zapping.sourceforge.net/cgi-bin/view/ZVBI/Download#Source_Code zvbi's project page]; these are actively maintained.

The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.

You may also use test/capture utility from the zvbi library to display printable closed caption data.
capture --dump-cc

To visualize the Vertical Blanking Interval on NTSC, issue

ntsc-cc -d /dev/vbi -c -w -r 11

Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.

In the zvbi test/ suite, osc similarly visualizes; cf. [[vbi images]]. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.

LifeView FlyVideo3000FM NTSC

2007-09-22T23:46:01Z

Liontooth: /* Recording with transcode */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. I've worked with up to five cards in one computer, though you need a powerful CPU to keep up with the data flow.

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[LifeView FlyVideo3000 PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot. With 2.6.19, I switched to tuner 95.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DIVX -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with medium-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for internal audio input (directly via the PCI bus), you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[LifeView FlyTV Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].

==External Links==
* [http://www.lifeview.com/usa/html/products/PCITV/FlyVideo3000-w1.htm LifeView product page]

LifeView FlyVideo3000FM NTSC

2007-09-22T23:44:52Z

Liontooth: /* Recording with mencoder */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. I've worked with up to five cards in one computer, though you need a powerful CPU to keep up with the data flow.

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[LifeView FlyVideo3000 PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot. With 2.6.19, I switched to tuner 95.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DIVX -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with medium-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for tv you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[LifeView FlyTV Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].

==External Links==
* [http://www.lifeview.com/usa/html/products/PCITV/FlyVideo3000-w1.htm LifeView product page]

LifeView FlyVideo3000FM NTSC

2007-09-22T23:43:47Z

Liontooth: /* Selecting the tuner */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. I've worked with up to five cards in one computer, though you need a powerful CPU to keep up with the data flow.

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[LifeView FlyVideo3000 PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot. With 2.6.19, I switched to tuner 95.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DIVX -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with high-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for tv you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[LifeView FlyTV Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].

==External Links==
* [http://www.lifeview.com/usa/html/products/PCITV/FlyVideo3000-w1.htm LifeView product page]

LifeView FlyVideo3000FM NTSC

2007-09-22T23:41:32Z

Liontooth: /* Introduction */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. I've worked with up to five cards in one computer, though you need a powerful CPU to keep up with the data flow.

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[LifeView FlyVideo3000 PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DIVX -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with high-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for tv you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[LifeView FlyTV Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].

==External Links==
* [http://www.lifeview.com/usa/html/products/PCITV/FlyVideo3000-w1.htm LifeView product page]

Webcam Devices

2007-08-07T23:24:00Z

Liontooth: /* Webcam drivers */

==Applications==

* [http://tldp.org/HOWTO/Webcam-HOWTO/index.html The Webcam HowTo]
** [http://tldp.org/HOWTO/Webcam-HOWTO/framegrabbers.html framegrabbing applications]
* [http://www.ekiga.org Ekiga] -- Ekiga is a free Voice over IP phone allowing you to do free calls over the Internet. Ekiga is the first Open Source application to support both H.323 and SIP, as well as audio and video. Ekiga was formerly known as GnomeMeeting.
* [http://www.firestorm.cx/fswebcam/ fswebcam] -- fswebcam is a neat and simple webcam app for Linux. It captures images from a V4L1/V4L2 compatible device or file, averages them to reduce noise and draws a caption using the GD Graphics Library which also handles compressing the image to PNG or JPEG. The resulting image is saved to a file or sent to stdio where it can be piped to something like ncftpput or scp.
* [http://motion.sourceforge.net motion] -- motion-detection using a webcam
* [http://www.stolk.org/sonic-snap/ sonic-snap] -- webcam application specifically suited for the Sonix sn9c10x chip
* [http://www.litech.org/spook spook] -- capture live video and audio and stream it over an IP network
* [http://julien.danjou.info/telak.html telak] -- display remote or local pictures on your desktop
* [http://vgrabbj.gecius.de/ vgrabbj] -- grabs a image from a camera and puts it in jpg/png format
* [http://www.linux-projects.org/ Videoview & Device Debugger] -- applications suited for some drivers present in the Linux kernel. Videoview supports the USB Video Class standard.
* [http://linux.bytesex.org/xawtv webcam] -- captures images and uploads them to a Web-Server via ftp or ssh in a endless loop

==Resources==
* [http://www.exploits.org/v4l/ Video for Linux resources] -- see Video: Security / Webcams / Monitoring
* For USB webcams, see also [http://www.qbik.ch/usb/devices/search_res.php?pattern=video&submit=Search%21 video devices] in the [http://www.qbik.ch/usb/devices/index.php USB device overview database]

==UVC webcams==

Do you have USB 2.0 controllers on your notebook and desktop? If so, you could benefit from higher resolutions with the Logitech Quickam for Notebooks Pro, Quickcam Fusion and Quickcam Orbit MP. All those webcams are 1.3MP devices and are supported by the [http://linux-uvc.berlios.de/ linux-uvc] driver. Note that the Quickcam for Notebooks Deluxe doesn't fall in that category; it's supported by the [http://mxhaard.free.fr/ spca5xx] driver.

Those 3 webcams also work in USB 1.1 mode, but are then limited to 640x480. In that case, you could go for the Quickcam Pro 5000, which is a 640x480 device supported by the linux-uvc driver.

UVC webcams are well supported, but you must be aware of a few issues.

* The linux-uvc driver is V4L2-only. This means applications which support V4L1 only will not work. V4L1 is officially deprecated, and have been removed from the kernel recently, so most drivers have or will switch to V4L2 anyway.

* The 4 webcams mentioned above compress images in MJPEG for resolutions up to 960x720. This means that applications must be able to decompress MJPEG streams to use the webcam at lower resolutions. Ekiga supports MJPEG compression.

==Webcam drivers==
(alphabetize by driver)

Many of these are out-of-tree kernel drivers.

* [http://webcam.sourceforge.net/ cpia] -- first generation of STM's Color Processor Interface (ASIC) [[Cpia]]
**Included in mainline kernel
**Supports a large number of USB devices by Aiptek, Creative, Digicom, Dynalink, Ezonics, Intel, Microtek, Pace, SuperCam, TCE, Terracom, Trust, Utobia, ZoomCam
**Supports some parallel port devices by Creative, CVideo, CU-SeeMe, Digicom, and ZoomCam
* [[cpia2]] -- second generation of STM's Color Processor Interface (ASIC)
**Included in mainline kernel from 2.6.18
**Supports the [[QX5 USB microscope]], the Swann Versacam MINI webcam, and other devices using the second generation of STM's Color Processor Interface (ASIC)
* [[em2880]]
**Supports the [http://videologyinc.com/cameras/ccd-board-camera-20K14XUSB.htm Videology 20K14XUSB webcam]
**Included in mainline kernel from 2.6.18 (em28xx)
* [http://www.linux-projects.org et61x251]
**Supports Etoms ET61X151 or ET61X251-based USB cameras
**Included in mainline kernel
* [http://icm532.sourceforge.net/ icm532]
* [http://linux-uvc.berlios.de/ linux-uvc] -- the USB Video Class Linux device driver
**Not included in the kernel (as of 2.6.18), but several distros have ready packages
**Supports several USB2.0 Logitech Quickcams, such as the Orbit MP, the Pro for Notebooks, the Pro 5000, the Dell Notebook, and the Cisco VT Camera II
* [http://popies.net/meye/ meye] -- the Sony Vaio PictureBook Motion Eye Camera Driver
**Included in 2.4 and 2.6 kernels -- see [[meye |documentation]]
**Supports the second version of the MotionEye camera (PCI vendor/device 0x136b/0xff01)
**A driver for the third version is being written, see r-engine below
* [http://nw802.sourceforge.net/ nw802]
* [http://alpha.dyndns.org/ov511/ ov511]
* [http://www.saillard.org/linux/pwc/ pwc] -- the new driver
**Available in the latest kernels
**Supports Philips USB webcams
**[http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome PWC wiki]
**[http://www.smcc.demon.nl/webcam/ Discontinued version]
* [http://qce-ga.sourceforge.net/ qce-ga/qc-usb]
**Kernel module package available in
***Debian stable ([http://packages.debian.org/stable/misc/qce-source qce-source])
***Deban testing and unstable ([http://packages.debian.org/unstable/misc/qc-usb-source qc-usb-source], see also [http://git.debian.org/?p=collab-maint/qc-usb.git;a=summary git repository])
**Supports Logitech Quickcam Express, LegoCam, Dexxa Webcam, Labtec Webcam (old model), Logitech QuickCam Notebook (some models)
* [http://www.informatik.uni-oldenburg.de/%7Edelwi/quickcam/ quickcam]
* [http://r-engine.sourceforge.net/ r-engine]
**Aims to support Sony Vaio Picturebooks (model PCG-C1M* and newer, PCI vendor/device 0x10cf/0x2011)
* [http://members.brabant.chello.nl/%7Ej.vreeken/se401/ se401]
* [http://sqcam.sourceforge.net/ sqcam]
**Supports webcams based on the sq905 chip, such as Volcano DG640E, Nexxtech Micro Digital Camera, Umax (Yamada) Astranugget; may work with Mito DG640E, Mitek CD10, Mitek 30P, GTW Electronics/ ShuoYing, Industrial(ShenZhen)Co.,Ltd SY-2102, Condord Eye-Q Easy / Eye Q Easy Too, Che-ez Snap, Hercules DualPix, Argus DC-1512, DC-1510, Gear to go, Magpix B350, Jenoptik JD 350, Concord Eye-Q Easy, PockCam
* [http://www.linux-projects.org/ Sonix SN9C10x]
**Available in the latest kernels as sn9c102
**Supports webcams based on the sn9c102 chip, such as the Genius VideoCam NB
**Another driver was in development here [http://sonix.sourceforge.net/ sonix]
**[http://tgnard.free.fr/linux/ sn9c101] -- patch for Trust Spacec@m
* [http://mxhaard.free.fr/ spca5xx]
**Supports webcams based on Sunplus Sonix Transvision Z-star/Vimicro Conexant Etoms chips
**Supports webcams such as Aiptek Pencam and Digital Dream l'espion
**See the long [http://mxhaard.free.fr/spca5xx.html list of devices]
* [http://syntekdriver.sourceforge.net/ stk11xx]
**Aims to support Syntek DC-1125/1135 cams
* [http://gkall.hobby.nl stv680] -- SANE backend
* [http://stv0680-usb.sourceforge.net/ sty0680]
* [http://home.t-online.de/home/free-photons/tv8532.html tv8532]
* [http://linux-uvc.berlios.de/ uvcvideo]
**USB Video Class driver
* [http://www.linux-projects.org/ w9968cf] -- included in the kernel
**Supports Winbond W9967CF or W9968CF-based USB cameras
** [http://winbond-webcam.sourceforge.net/ w9967cf (obsolete)]
* [http://www.royale.zerezo.com/zr364xx/ zr364xx]
**Supports the webcam mode of cameras based on the ZR364xx chips from wendors like Aiptek, Concord, Creative, Genius, Maxell, Fujifilm, Ricoh, Pentacon, Mustek, Konica, Umax etc.
* [http://www.linux-projects.org zc0301] -- included in the kernel
**Supports Z-Start/Vimicro ZC0301-based USB cameras
* [http://zc0302.sourceforge.net zc0302]

V4L channel script

2007-07-17T15:33:29Z

Liontooth: /* Hardware */

==The channel scripts==

===Introduction===

This simple script, with its companion timestamper, is designed to capture television programs on a regular schedule and store the recordings in a dated directory tree along with the closed captioning text files. Because the scripts are so elementary, they are very easy to debug, and the script has been running flawlessly for more than a year now.

The script is designed to handle several capture cards for simultaneous capture, and jobs are scheduled per card in a cron job or issued manually for a single program. Files are saved to the first drive with "tv" in its name and at least 1GB of free space.

The use of [http://www.tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html bash] is elementary and can surely be improved on; I'm self-taught. Since the wiki uses the GPL license, the scripts are hereby GPL'd; feel free to modify.

===Hardware===

My setup is an amd64 motherboard with on-board NICs, sound, and video, and five PCI slots ([http://www.giga-byte.com/MotherBoard/Products/Products_Spec_GA-K8NS%20Ultra-939.htm Gigabyte K8NS Ultra-939]), so there's lots of room for grabber cards. It currently uses three [[FlyVideo3000FM NTSC]] and two [[FlyTV_Platinum]] (saa7134) cards. I chose them because I can get sound directly off the cards and don't need a patch cable for each one to a sound card.

The three capture cards are loaded as follows:

saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1

The CPU is an AMD Athlon 64 dual core 4600+ (939); each mencoder session uses about 20% of the CPU. Results from five simultaneous capture is now excellent. The script assumes you get the signal off the air; cf. the "us-bcast" parameter.

I would like to switch to [[PcHDTV |pcHDTV-3000]], but these cards don't have closed captioning support yet.

I capture to SATA drives; the board has support for four of these. The OS is installed on a PATA drive.

===Software===

The OS is Debian sid with a 2.6.18-1 kernel. I generally leave the OS alone, but occasionally update some of the applications.

Mencoder is used to grab and compress the footage, using DIVX and mp3lame and an avi wrapper (suggestions for improvements are welcome). I'm currently running [http://www.debian-multimedia.org/ Christian Marillat's] unofficial 1:1.0-pre8cvs20061002-0.0 Debian package.

We don't don't view the footage on the capture machine, but use [http://nfs.sourceforge.net/ NFS] to view the captured files on other machines. On OSX, you can view the avi files with VLC; Windows is untested, but the files should play after installing the DIVX codec. Users can be given access to the recording machine's crontab. On X11, [http://docs.kde.org/development/en/kdeadmin/kcron/index.html kcron] provides a user-friendly interface. The status of the capture machine can usefully be monitored with gnome-system-monitor.

For listings, we use [http://freeguide-tv.sourceforge.net/ Freeguide].

===Capture script===

<pre>

#!/bin/bash
#
# /usr/local/bin/channel
#
# Script to record analog television programs to .avi files, using mencoder, and
# the associated closed captioning in a separate identically named .txt file
#
# You need to include /usr/local/bin in cron's PATH (see kcron's Variables)
# Use the bash interpreter -- /bin/bash, not /bin/sh
#
# Usage: channel <channel number> <duration> <title> <capture card number>
#
# For instance,
#
# channel 28, 30min, "BBC World News", 1
#
# Input parameter rules:
# * commas are optional
# * give duration (recording time) in minutes
# * the word "min" (for minutes) is optional
# * a space signals a new parameter
# * enclose multi-word titles in quotes
# * don't use apostrophes in titles -- messes up searching of captured text
# * the default card number is 1
#
# Changelog
# 2005-01-12: added $! to terminate ntsc-cc and channel-timestamp
# 2005-04-15: added $DEV input parameter to handle multiple tv cards
# 2005-04-23: added aumix -d /dev/mixer1 -1 R for sound off the saa
# 2005-05-13: added mixer device number
# 2005-05-16: new directories are created with 775
# 2005-05-22: added busy test
# 2005-10-07: use zvbi-ntsc-cc, soon in libzvbi 0.2.17
# 2006-02-15: removed colon from filename (FIL=)
# 2006-08-18: added drive assignment routine (checks for space)
# 2006-09-04: switched from oss to alsa (2.6.17 kernel)
# 2006-09-14: check /dev/vbi$DEV instead of /dev/dsp$DEV in busy loop
# (you could use /dev/video$DEV)
# 2006-09-20: added some messages at the end, using 24-hour time
# 2006-09-24: added XDS information to closed captioning
#
# ***************************************************************************

# First some checks triggered by manual mode

if [ "$1" = "" ] ; then
echo "Use news <channel number> <recording time in minutes>";
echo "Please give a channel! Valid channels are 2, 4, 5, 7, 9, 11, 13, and 28.";
exit
fi

if [ "$2" = "" ] ; then
echo "Use news <channel number> <recording time in minutes>";
echo "Please give a recording length in minutes!";
exit
fi

if [ "$3" = "" ] ; then
echo "Use news <number> <duration> <title>";
echo "Please give a title to the recording!";
exit
fi

# Define the video and VBI (vertical blanking interval) device to use
# Default is /dev/video1 and /dev/vbi1
if [ "$4" = "" ] ;
then DEV=1
else DEV=$4
fi

# Define variable DRV to contain the first tv drive with more than 1% free
for i in $(df | cut -d'/' -f4 | grep tv | sort); do
if [ "$(df /$i | grep $i | cut -b 52-54)" -lt 99 ]
then DRV=$i
echo "Using drive" $DRV "with" "$(df -h /$i | grep $i | cut -b 35-37)GB free"
break
fi
done

# Define variable DIR to contain nested directories for
# yyyy, yyyy-mm, and yyyy-mm-dd (today's date)
DIR=/$DRV/$(date +%Y)/$(date +%Y-%m)/$(date +%F)

# Create the directory (and any missing parents) if needed
if test ! -d $DIR
then mkdir -p -m 775 $DIR
fi

# Strip the comma, if any, from the channel name
CH=${1%,*}

# Set the channel (current user needs X11 access)
# You can also set this in mencoder with tv://$CH or channel=$CH
v4lctl -c /dev/video$DEV setchannel $CH

# Convert channel number to name for the base file name
case $CH in
2) CH=KCBS;;
4) CH=KNBC;;
5) CH=KTLA-WB;;
7) CH=KABC;;
9) CH=KCAL;;
11) CH=KTTV-FOX;;
13) CH=KCOP-UPN;;
28) CH=KCET;;
esac

# Strip the {min,|min|,} if it's there, from the duration
TIM=${2%m*}; TIM=${TIM%,*}

# Strip the comma, if any, from the title, and convert spaces to underscores
TIT=_`echo ${3%,*} | sed -e "s/ /_/g"`

# Define the file name (escape underscore before $) and print it to screen
FIL=$(date +%F_%H%M)\_$CH$TIT; echo Preparing to record $FIL

# Check if the capture device is busy
BUSY="Capture card $DEV is busy -- will try for another five minutes \n"
START=$(date +%s); TARGET=$[$START + $[5*60]]

while [ "$(sudo lsof /dev/vbi$DEV)" != "" ]; do
if [ $TARGET -gt $(date +%s) ]
then echo -ne $BUSY
sleep 5; BUSY=""
else echo "Recording of $FIL aborted -- capture card $DEV is not available"
exit
fi
done

# Convert minutes to seconds and adjust down five seconds for the hardware to reset
TIM=$[$[TIM*60]-5]

# Adjust the duration down by the delay added by the busy check, exit if no time left
TIM=$[TIM-$[$(date +%s) -$START]]; if [ $TIM -lt 1 ]; then exit; fi

# Start the timestamp script and background
channel-timestamp $CH $TIT $DIR $FIL &

# Get the PID for the timestamper
TMSP=$!

# Start cc capture and background the process
zvbi-ntsc-cc -d /dev/vbi$DEV -cpx >> $DIR/$FIL.txt &

# Get the PID for the closed captioning
NTSC=$!

# Restore default sound sttings and open up the sound channel on the capture card
/usr/sbin/alsactl restore $DEV

# Set any additional values (none currently needed)
#v4lctl -c /dev/video0 color "50%"

# Record the footage (note this assumes direct audio)

# Use this to control the bitrate -- default is 800
#lavc -lavcopts vbitrate=1800 -oac mp3lame -lameopts cbr:br=128 -endpos $TIM -o \

echo "Initiating recording of $FIL from channel $1"
echo "on capture card $DEV, at $(date +%T), duration $TIM seconds"

mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:adevice=hw.$DEV:alsa:input=0:amode=1:normid=4 -ffourcc DIVX -ovc \
lavc -oac mp3lame -lameopts cbr:br=128 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null

# Stamp the file with receipts to verify capture success
echo -e "\n"
ls -l $DIR/$FIL.*
echo -e "\nCompleted capture on $(date +%A\ %d\ %B\ %Y) at $(date +%T)"
echo -e "Video and audio file size" $(ls -sh $DIR/$FIL.avi | cut -d' ' -f1)
echo -e "Closed captioning file size" $(ls -sh $DIR/$FIL.txt | cut -d' ' -f1) "\n"

# Terminate the closed captioning and the timestamper
kill $NTSC $TMSP

# EOF

</pre>

The only part of the script that gave me trouble over a prolonged period was the transition between recordings. Sometimes it takes the kernel several seconds to activate a card, and if the recording length doesn't compensate down, the next scheduled recording bumps into a busy device. However, this problem appears to have been fully solved in the current busy script, which waits for up to five minutes and shortens the recording time by the time waited.

I also tended to lose some programs when a drive was full, since I often missed the exact moment, so I've added some lines to look for a drive with space. I was filling drives at the rate of 4GB a day and had room for four drives, so it would take a year to fill a set of 400GB drives.

===Variant: capture to H.264 using alsa===

If you want to capture to H.264 instead, and use the new [[saa7134-alsa]] module for getting sound, you can use this (and drop aumix from the script, as it doesn't appear to understand alsa's device notation):

<pre>
mencoder -tv driver=v4l2:device=/dev/video$DEV:fps=30000/1001:chanlist=us-bcast:\
audiorate=32000:alsa:adevice=hw.$DEV:input=0:amode=1:normid=4:width=576:height=480 \
-ovc x264 -x264encopts bitrate=500:bframes=2:subq=2:me=2:frameref=2 \
-oac mp3lame -lameopts cbr:br=64 -endpos $TIM -o $DIR/$FIL.avi tv:// > /dev/null
</pre>

===Time-stamping script===

The main script calls this little routine for timestamping the closed captioning files. this is useful only if you want to set up a searchable database of text.

<pre>
#!/bin/bash
#
# /usr/local/bin/channel-timestamp
#
# This shell script is used to add timestamps to closed captioning
# It is called by the main recording script, /usr/local/bin/channel.
#
# Add -xv to the top line to get verbose messages
#
# Changelog:
# 2005-01-12: The parent script now handles child process terminations
# 2005-01-13: Timestamps could use XDS data -- start with the date and
# include title (not implemented)
#
# *****************************************************************

# Write the first timestamp
echo $(date +%F_%H:%M:%S)_$1$2 >> $3/$4.txt

# Write a timestamp every ten seconds
while true
do
sleep 10
echo $(date +%F_%H:%M:%S)_$1$2 >> $3/$4.txt
done

# EOF

</pre>

===Crontabs===

While programs can be captured manually using the channel script, I use [http://www.linuxhelp.net/guides/cron/ cron] for scheduled recordings.

Here are some examples of crontab usage:

<pre>

# Folders to search for program files.
PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Email output to specified account.
MAILTO=tna
# KCAL 9 News at 9pm
0 21 * * 6 channel 9, 60min, "News at 9pm", 1
# KNBC 4 Meet the Press
0 8 * * 7 channel 4, 60min, "Meet the Press", 2
# KABC 7 World News Tonight
30 17 * * 7 channel 7, 30min, "World News Tonight", 1
# KCBS 2 60 Minutes
0 19 * * 7 channel 2, 60min, "60 Minutes", 1
# Fox 11 Morning News at 6 AM/ Good Day LA
0 6 * * 1,2,3,4,5 channel 11, 60min, "Morning News at 6", 1
# KCET 28 BBC World News
30 5 * * 1,2,3,4,5 channel 28, 30min, "BBC World News", 3

</pre>

You can edit crontab with kcron or with the "crontab -e" command. It's also possible to use scripts to add jobs:

crontab -l >> newjob | crontab newjob

If you have a complex crontab you don't want to lose, back it up with "crontab -l > crontab-$(date +%F_%H:%M)".

Btaudio (bt878)

2007-07-17T15:24:40Z

Liontooth: /* Supported cards */

The btaudio kernel module allows you to get the audio from your tuner card directly over the PCI bus without using a patch cable to your sound card. This is useful if you would like to reserve your sound card for other functions, if you want to have multiple tuner cards in one computer, or if your sound card does not handle full-duplex.

===Instructions===

* [[btaudio_kernel_instructions | Gerd Knorr's instructions]] (copied from the 2.6.12-rc2 kernel and lightly updated)
* MythTV wiki: [http://www.mythtv.org/wiki/index.php/Btaudio setting up btaudio on an ATI TV Wonder card]
* [[TVCapture_98 | Failed attempt]] at getting the sound directly off a LifeView FlyVideo3000 bttv card
* Note that [[saa713x_devices | saa713x cards]] unproblematically let you get the audio directly

===Supported cards===

Although all cards with BT87x chips are capable of supporting btaudio, not all cards do. In some cases, the manufacturer elected not to connect the TV tuner analogue audio out to one of the two ADC analogue inputs, which means you'll get no sound from btaudio. In other cases, (see [[#Initialization failures |Initialization failures]] below or [[TVCapture_98#Getting_the_sound_directly_off_the_tv_card | TVCapture_98]]), the card is wired correctly, but not adequately initialized, so that the btaudio driver fails.

According to the [http://www.mythtv.org/docs/mythtv-HOWTO-23.html#btaudio MythTV HowTo], you need a bttv tuner device with an MSP34xx chip. This is incorrect. While a digital signal processor such as the MSP34xx is required for btaudio's digital mode, any bt87x card has the required hardware to work with btaudio's analog mode.

These cards are known to work with btaudio; the real set of working cards is much larger:

ATI TV Wonder
Hauppauge WinTV-radio with dbx-TV stereo, model 401
Hauppauge WinTV-Theater, model 495, 498 (Europe)
Hauppauge WinTV Express, models 751, 753 (but see note)

Note: Hauppauge model labels are often uninformative. For example, the box labeled model 753 may contain one of these:
board #44804 rev #D183, auto card=10; tuner TCL2002MB-3 (hidden sticker),
but has to be forced to tuner=41 (Phillips PAL-MK(FI1216MK)
board #44804 rev #D108, auto card=10; tuner FI1216MK15 (hidden sticker),
autodetected as tuner=5.

The following cards are said not to work, but it's not known if they are wired the wrong way, not properly initialized, or just mistakenly thought not to work:

Pinnacle Studio PCTV Pro
ATI TV Wonder VE
Leadtek Winfast 2000 XP (PAL, UK and NTSC)
I/O Magic PC-PVR

Some cards are reported to work, but the quality is poor; there may be individual differences within a model series.

===Technical background===

====Overview====

The analog mode of the btaudio driver should just work on any BT87x card. The functions it supports are all integrated into the BT87x; all that is required is that the analog audio from the tuner is connected to the analog audio in on the chip, which in most cases it will be. The digital mode requires an additional digital audio source, such as the MSP34xx, which not all cards have. The following information is assembled largely from David Martin's informative posts to the v4l mailing list in April 2005.

* [http://www.ortodoxism.ro/datasheets/Conexant/mXttzww.pdf Fusion 878A datasheet] from [http://www.datasheetcatalog.com/conexant/1/ Conexant]

====Analog mode====

The bt878 and bt879 (the latter no longer in production) include a high-frequency Analog to Digital Converter, supporting both 8 and 16 bits audio at 448000 samples per second.

Juan Domenech Fernandez has written up his experiments with the "low frequency ADC that comes with the Bt878A chip" in two parts; these articles provide valuable technical detail about the hardware driven by btaudio:

* [http://www.domenech.org/bt878a-adc/index-e.htm Analog to Digital Converter with 16 bits and 448000 Samples per second based in the Bt878A]
* [http://www.domenech.org/bt878a-adc/index-decimator-e.htm btaudio.c module modification to get 896000 Samples per second with the Bt878A ADC]

The 878 audio ADC has two inputs - STV (Sound TV) and SML (Sound Mic/Line). The 878A also has an FM input, SFM (Sound FM), used only if the card has a radio tuner. The BT879 has a pair of FM/FM stereo inputs. The cards all have a digital audio packetizer and FIFO buffer for DMA audio transport across the PCI bus to the host PC. All of this is on the BT87x silicon - identical on every card - and accessible via the btaudio driver. As a result the btaudio driver is almost entirely card agnostic. It only does a few things, roughly something like:

# Control the ADC switching mux to determine which of the two analogue input lines will be sampled.
# Control the ADC input gain (ie. the volume)
# Control the digital low pass filter to set the decimation factor and, hence, the digital output frequency.
# Control the digital audio packetizer input selection (the ADC or the external digital line in).
# Set the digital audio packetizer output mode and characteristics for the PCI bus data transfer.

On the [http://www.ortodoxism.ro/datasheets/Conexant/mXttzww.pdf 878A datasheet], the relevant pins are 94, 98, and 100. You need to inspect your card to see how the card manufacturer has used these pins:

http://www.domenech.org/bt878a-adc/conexant-fusion-878a-pin-out-bt878a-adc.png

These ADC pins serve the following functions:

<table padding="5" border="1" cellpadding="5">
<tr> <td> Pin </td> <td> Signal </td> <td> Description </td></tr>
<tr> <td> 100 </td> <td> STV I </td> <td> TV sound input from TV tuner. </td> </tr>
<tr> <td> 98 </td> <td> SFM I </td> <td> FM sound input from FM tuner. </td> </tr>
<tr> <td> 94 </td> <td> SML I </td> <td> MIC/line input. </td> </tr>
</table>

Analogue mono audio comes via the tuner or an external input source onto one or both of the BT87x analogue audio input pins. The btaudio driver controls the BT87x audio A/D and digital audio packetizer and provides a pseudo OSS device for applications to get access to the sound stream.

There are cases where the TV card designer elected NOT to connect the TV tuner analogue audio out to one of the two ADC analogue inputs (usually pin 100 on the BT87x). In this case, and in this case only, you will not get the broadcast audio. You will get static or silence. Nothing short of a soldering iron will help you.

However, the majority of cards have the required connections. Most designs seem to hook up the tuner mono TV audio to the BT87x STV pin. In some cases cards have multiple signal sources (a tuner and an external composite video and audio input pair, for example). In these designs there will be an analogue switching IC between the two input sources and the BT87x. Usually the the audio inputs bypass the switcher IC and the tuner is on the STV pin and the auxiliary audio is on the LINE pin. I have seen at least one card where the switcher IC routes both audio and video, and with the audio output from the switch only going to the external audio out, so you can use btaudio for the TV tuner, but not for the external audio input.

When you do get sound, the quality of the output can vary wildly from card to card (from good to unusably awful). Sometimes you can play around with sample frequencies and input gain settings and improve things.

====The analog mixer====

The analog device created by the btaudio driver has three mixer channels, called Line1, Line2, and Line3. The wiring varies; the sound can come through on different lines (cf. [[btaudio#Instructions | Instructions]] section above). One of the line inputs that show up in the mixer is an internal mux switch between STV and SML. According to the datasheet, sections 2.15.1 and 6.3, the mux is controlled by bits 24-25, A_SEL; legal values are 0 (STV, default), 1 (SFM), 2 (SML), or 3 (no mux), cf. pp. 165-6.

The other is a switch for a single stage 6dB preamp boost for the audio signal. The input gain control in the audio A/D (Line2 in the mixer) has 15 gain settings, from 0.5 times (-6db) to 3 times (10db) - this is in addition to the 6dB switchable audio preamp boost. What gain setting you need depends on the magnitude of the input signal from the tuner. The audio A/D is designed with a nominal input signal of 0.5V RMS, but the tuner input could be wildly different.

The ADC audio stage runs a 1.792MHz clock with valid hardware decimation values between 4 and 15 (controlled by bits 8-11, DA_SDR, of local register 0x10C, Audio Control Register (GPIO_DMA_CTL).

Juan uses these commands to test the device:

sox -w -r 448000 -t ossdsp /dev/dsp1 -t .wav test.wav

The dmesg results indicates which decimation values are used to downsample, yielding this table of twelve valid hardware rates:

4: 448 kHz
5: 358.4 kHz
6: 298.67 kHz
7: 256 kHz
8: 224 kHz
9: 199.1 kHz
10: 179.2 kHz
11: 162.9 kHz
12: 149.3 kHz
13: 137.8 kHz
14: 128 kHz
15: 119.47 kHz

He notes that by editing the btaudio driver, it's possible to make the ADC accept a decimation value lower than 4 for even higher sampling rates.

====Digital mode====

In the case of analog broadcast capture, digital audio inputs will always come via an external source - normally a NICAM or FM-FM stereo decoder IC which provides an i2s output signal to the BT87x digital audio input line. Those are generally controlled (control meaning mode and input selection) via i2c using the tvaudio driver.

However, most analogue capture cards have nothing connected to the inputs and they don't work - if you try and use the btaudio digital input, your application will freeze and nothing will happen.

The long and short of this is that analog mono audio via btaudio should either "just work" or it won't work at all and there is essentially nothing you can do about it if it doesn't, although I would expect the latter case to be in the minority. Digital audio won't work in the majority of cases because there is no external digital audio source to drive it.

====Initialization failures====

Petr Vandrovec describes a case where a bt878 card fails to work with the btaudio driver unless it is first initialized by a Win98 driver:

:"On my hardware (AverMedia TVCapture98) digital channel is not connected anywhere, and analog grabbing works only if Win98 with btpcivid.vxd from Feb 25 1999 (105492 bytes) are booted after poweron, but before Linux. Without performing initialization by this .vxd only samples with value 0x7FFF are captured, as some voltage reference is not programmed or something. And only this .vxd seems to do needed intialization - newer .vxds and WDM *.sys drivers do not seem to perform this initialization."

It is the tvaudio driver that handles the initialisation and controls external i2c-connected audio processors. The bttv driver itself contains GPIO controls for connected tuners, muxes/switches, and the like. There are already Aver card-specific audio initialisation functions in the bttv driver to handle this case -- Petr himself wrote them. If there are initialization problems, they occur outside of the btaudio driver.

See the [http://platan.vc.cvut.cz/btaudio/bad.png captured graph after power-on] and compare with the [http://platan.vc.cvut.cz/btaudio/ok.png graph captured after booting Win98]. The signal in the latter comes from a square wave generator with digital low-pass filter at ~24.85kHz. Vertical lines denote 49.7kHz samples from tone generator, and whole thing was grabbed at 448kHz.

Update: Ytlin reports that he initialized his cards successfully with another driver for MS Windows, the LGPL'd [http://btwincap.sourceforge.net btwdmdrv]. Since this driver is open source, it may be possible to use it to determine what needs to be done by the Linux driver.

Saa713x devices

2007-07-17T15:13:16Z

Liontooth: /* Other */

== Introduction ==

TV cards based on the saa713x chips are well supported. The picture quality is typically high, and the sound can be taken directly from the TV card or through a patch cable to your sound card. On the [[text_capture | text capture]] front, both teletext and NTSC closed captioning are supported.

For an excellent guide, see Gentoo wiki's [http://gentoo-wiki.com/HARDWARE_saa7134 HARDWARE saa7134]. See also [http://www.datasheetarchive.com/datasheet/pdf/4366.html Philips saa datasheets]

==Supported cards==

See the list of [[CARDLIST.saa7134 | currently supported saa7134 devices]].

(This page design seems the best one -- a link to the supported cards, but then a list of the cards by vendor below, with links for help. The [[Bttv devices (bt848, bt878) |bttv]] and [[cx88 devices (cx2388x) |cx88]] pages should be redesigned along the same lines.)

==Sound support==

Support for DMA sound, or sound taken directly off the PCI bus, has improved in the 2.6.16 kernel, thanks to the work of Ricardo Cerqueira and others. There are now two separate drivers for DMA sound, saa7134-alsa and saa7134-oss. In order to enable these in the kernel, you must first have selected support for ALSA and/or OSS under Sound. If you build both DMA devices as modules, you can use both alternately, though they cannot both be loaded at the same time.

While the saa7134-oss is listed as deprecated, there are still programs that have difficulties using ALSA's device enumeration, and the oss module remains useful.

These modules do not require parameters during insertion; for details see [[saa7134-alsa]].

== Installation ==
See [[Generic SAA7134 Card Installation]] for how to properly setup your saa7134-based tv tuner card or use the installation instructions for your specific card:

=== [[Avermedia]] ===
As described in [[AverTV_305/307_linux_user_guide |AverTV 305/307 linux user guide (russian)]], the following cards are supported:
* AVerTV 305
* AVerTV Studio 305
* AVerTV 307
* AVerTV Studio 307
In addition, the following cards are known to work:
* [[AVerMedia Cardbus E500]]
* [[AVerMedia Cardbus Plus E501R |AVerMedia Cardbus Plus E501R (russian)]]
* [[AverMedia M156 / Medion 2819]]
* [[AVerMedia DVD EZMaker]]
* [[AVerMedia AVerTV GO 007]]
* [[Avermedia AVerTV GO 007 FM]]
* [[AVerMedia AVerTVHD MCE A180]]
* [[AVerMedia Cardbus Hybrid TV FM E506R]]
* [[AVerMedia AverTV Hybrid+FM PCI A16D]]

=== Bona ===
The brand is also refered to as Mentor. [http://www.bona.com.tw:8080/ Bona Website]
* [[Bona TV-PCI]]

=== Canopus ===
* [[KTVX-CB (aka ITACHU),CardBus]]

=== Compro ===
* [[Compro VideoMate T300]]
* [[Compro VideoMate T200a]]
* [[Compro VideoMate T200]]
* [[Compro VideoMate TV Gold-Plus]]
* [[Compro VideoMate TV PVR/FM]]
* [[Compro VideoMate TV Gold-Plus PAL]]

=== KNC One (KNC1) ===
* [[KNC One TV-Station DVR]]
* [[KNC One TV-Station RDS]] / Typhoon TV Tuner RDS

=== KWorld ===
* [[Kworld ATSC-110 |ATSC-110]]
* [[Studio TV Terminator]] (a.k.a. Global TV Terminator)
* [[Kworld NB-TV 100 (VS-NBTV100) CardBus]]
* [[Tevion DVBT-220RF|Tevion/KWorld DVB-T 220RF]]

=== Lifeview ===
* [[FlyVIDEO2000]]
* [[FlyVideo3000FM NTSC|FlyVideo3000FM and FlyVideo3000]]
* [[FlyVideo3000 PAL-N]]
* [[FlyDVB-T Hybrid]], CardBus or PCI
* [[FlyDVB-T Duo CardBuS PAL]]
* [[FlyTV Platinum]]

=== Mercury ===

* [[Mercury TV PAL]]

=== Pearl ===

* [[Auvisio TV Tuner & Video Capture Card]]

=== Pinnacle ===
* [[Pinnacle PCTV 40i]]
* [[Pinnacle PCTV 50i]]
* [[Pinnacle PCTV 110i]]
* [[Pinnacle PCTV 300i]]
* [[Pinnacle PCTV 310i]]
* [[Pinnacle PCTV Stereo]]
* [[Pinnacle PCTV Stereo XE]]

=== Sabrent ===
* [[Sabrent SBT-TVFM]]
* [[Sabrent TV-PCIRC]]

=== Terratec ===
* [[Terratec Cinergy 250 PCI]]
* [[Terratec Cinergy 400]]
* [[Terratec Cinergy 400TV mobile]]
* [[Terratec Cinergy 600]]
* [[Terratec Cinergy HT PCI]]

=== Tevion ===
* [[Tevion MD 9717]]
* [[Tevion DVBT-220RF]]

=== Vivanco ===
* [[Vivanco Cardbus DVB-T]]

=== Other ===
* [[Smartv_card |SmartTV Card]]
* [http://techcomindia.com/itemdetail.asp?Cat=&CatID=&prodid=501&ProdName=SSD%2DTV%2D670 TECH-COM, Card Model: SSD-TV-670 ]

LifeView FlyVideo3000FM NTSC

2007-07-12T21:01:28Z

Liontooth: /* Remote control */

[[Image:LifeView-FlyVideo-3000FM.jpg|right]]

===Introduction ===

This card works perfectly -- it gets 640x480 frames, audio directly from the card, and closed captioning. Up to four cards can be placed in one computer, though you need a powerful CPU to keep up with the data flow. (I even managed to get five cards to work -- alternating between the 3000FM and the [[FlyTV Platinum |Platinum]] cards.)

For detailed images of the various slightly different models, see [http://www.bttv-gallery.de/ bttv gallery]. Most of LifeView's saa713x cards fit both 32-bit PCI slots and 64-bit PCI-X slots -- see the telltale second slit in the foot of the card.

See also [[FlyVideo3000_PAL-N]].

=== Identification ===

The 3000 and the 3000FM cards are identified as having the same subsystem:

lspci -vvv: 02:0a.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev 10)
Subsystem: Unknown device 5169:0138

The cards have the [http://www.semiconductors.philips.com/pip/SAA7133HL_V101.html saa7133HL-v101] chip.

=== Loading the right driver ===

The card needs the saa7134 driver, which should be built as a module in the kernel. When the module is inserted, your particular variant may be autodetected or you may need to manually configure it. Try the simplest method first:

modprobe saa7134

If the card is not working right, and you have a recent kernel, try this:

modprobe saa7134 i2c_scan=1

If both fail, you may need to configure the card manually by passing values for the card and/or tuner.

=== Selecting the tuner ===

Use card 2 in the Documentation/video4linux/CARDLIST.saa7134. Versions of FlyVideo 3000 are shipped with different [[Tuners |tuners]]; to find yours, grep on the card and your television standard to pull up relevant alternatives:

grep Philips Documentation/video4linux/CARDLIST.tuner | grep NTSC

For the NTSC tuner on the FlyVideo 3000 (without the radio), I found 17 was the right one. The FlyVideo3000FM has a different tuner, and I found 43 works, but only gives you channels below 60. Tuner 39 gives you all channels. In kernel 2.6.12 I had to reboot to reset the tuner -- modprobe didn't do it -- but in kernel 2.6.18 the tuner reset without a reboot.

=== Inserting the module ===

For this card, if autodetection fails, you can insert the module with the following options:

modprobe saa7134 card=2 tuner=39

The 3000 version of the card (without radio) takes tuner 17.

When you've found a method that works -- autodetection or manual configuration -- include the working options in your modules configuration setup. For details, see [[Generic_SAA7134_Card_Installation#Drivers_probing]].

=== Getting PCI audio ===

You can get the audio from the card through the PCI bus instead of through the audio out jack and a patch cable to your sound card.

For kernels 2.6.15 and later, see [[Saa7134-alsa]] for details on both ALSA and OSS sound.

For earlier kernels, adding "oss=1" as an insmod parameter will create /dev/dsp1 and /dev/mixer1. For detailed instructions, see [http://gentoo-wiki.com/HARDWARE_saa7134 Gentoo's saa7134 wiki].

In earlier kernels, you use

aumix -d /dev/mixer1 -I

to set the recording channel to 1.

=== Recording with mencoder ===

Use something like this:

mencoder tv:// -tv driver=v4l2:device=/dev/video1:fps=30000/1001:chanlist=us-cable:audiorate=32000:
adevice=/dev/dsp1:input=0:amode=1:normid=4 -ffourcc DIVX -ovc lavc -lavcopts vcodec=mpeg4:mbd=2
-oac mp3lame -lameopts cbr:br=128 -endpos 60 -o output.avi

This gives me stereo audio with high-quality video. I found that if I included "-of mpeg" to create a true mpeg stream, the audio got delayed -- there are no sync problems with the avi file.

=== Recording with transcode ===

You can also use transcode to record:

transcode -x v4l2,v4l2 -M 2 -i /dev/video$DEV -p /dev/dsp1 -e 32000,16,2 -y ffmpeg -F mpeg4
-c 00:30 -g 640x480 -f 29.970,4 -I 1 -u 1024 -Q 3 -E 32000,16,2 --lame_preset medium -o output.avi

Note the "-e 32000,16,2", letting transcode know about the parameters of the audio stream from the saa7134 card.

The files produced in this manner are almost twice as large as the ones produced by the mencoder command above, but show significantly less pixillation. CPU utilization is also about double. For the saa7134, 48000Hz is only valid for external audio input to the card; for tv you have to use 32000Hz.

=== Loading multiple cards ===

If you have more than one card in the same machine, and want to control which devices they create, you can use this sort of thing with kernels before 2.6.15:

saa7134 video_nr=1,2,3 vbi_nr=1,2,3 mixer_nr=1,2,3 radio_nr=1,2,3 card=2,2,2 tuner=39,39,17

With 2.6.15 and later kernels, use this instead (drop the mixer and add a line for the audio driver):

saa7134 card=2,2,2 tuner=39,39,17 video_nr=1,2,3 vbi_nr=1,2,3 radio_nr=1,2,3
saa7134-alsa index=1,2,3

In /etc/modprobe.d/saa7134, I use this for five different cards (including two [[FlyTV Platinum |Platinum]] cards):

options saa7134 card=2,54,2,54,2 tuner=39,54,39,54,17 video_nr=1,2,3,4,5 \
vbi_nr=1,2,3,4,5 radio_nr=1,2,3,4,5 disable_ir=1,1,1,1,1
install saa7134 /sbin/modprobe --ignore-install saa7134; /sbin/modprobe saa7134-alsa
options saa7134-alsa index=1,2,3,4,5

This creates video1, vbi1, radio1, and the alsa device hw:1 for the first card, and so on up.

=== Remote control ===

With the FlyVideo 3000(FM), you should have the small grey credit-card sized remote. And yes, this is [http://www.mail-archive.com/video4linux-list@redhat.com/msg04784.html supported] and should be working (I haven't tested it).

For instructions, see [[Generic_SAA7134_Card_Installation#Remote_setup]].

=== Closed captioning ===

Closed captioning on saa713x is now working; Michael Schimek has added support to libzvbi (mid-May 2005); see [[Text capture]].