Capture Application

The cx88 package includes a simple capture application, which is (at least currently) also called 'cx88'--really creative naming, right? This app uses a multithreaded architecture in which a data source thread is spawned for each cx88 device to handle device configuration and to wait for wait for data buffers to be filled by the driver. The application includes a modular capture architecture that allows an arbitrary number of capture feeds to be created, each running in its own thread. A list of capture feeds is registered with each data source thread, and as buffers become available, the data source threads submit them to the capture feeds for further processing. For example, a single MPEG TS data source thread may be associated with a UDP capture feed and two file capture feeds, allowing the captured MPEG video to be simultaneously streamed live over a UDP socket and stored in two separate files. The main application thread is responsible for processing interactive input commands from the user or a remote control connection (see below).

Usage

The capture app recognizes the following options:

-d <device name> : Specifies the device node under /dev from which data should be captured. At least one -d directive must be specified. Multiple -d directives may be specified if multiple capture streams are necessary; for example, when capturing both raw video and audio.

-x <filename> : Specifies the XML channel configuration file that should be used. If this option is omitted, the application will attempt to use ~/.cx88.xml.

-c <string> : Specifies the channel to from which to start capturing. The channel name should follow the channel naming rules of the XML configuration file (see below). If this option is omitted, the default channel from the XML configuration file is used.

-u <URL> : Specifies a destination URL to which captured data should be sent. The following URL formats are currently supported:

• udp://hostname:port : Send data over UDP connection to specified hostname/IP address, e.g. udp://localhost:8802

• tcp://hostname:port : Send data over TCP connection to specified hostname/IP address, e.g. tcp://192.168.0.2:8802

• file://filename : Send data to specified file. If the path already exists, the new data will be appended to it. Device nodes (files under /dev) and named FIFOs may be used.

• oss://filename : Send audio data to specified OSS-compliant output device. This is a special case of the file:// URL that issues OSS ioctls to set the stereo mode and bitrate of the target device to appropriate values.

  • The -u option may be used multiple times when invoking the application--Each URL specifies a capture stream that will be associated with the current device (this most recent -d option, or if -d has not yet been specified, the first one). For audio devices, absence of -u options will allow other applications to use the OSS interface of the audio device, while the cx88 capture app is used to control tuning.

-t <filename> : Specifies a libtuner configuration file for use with the current device. Libtuner configuration is typically specified in the XML channel configuration file, but this option may be used to provide additional configuration options. These options should be in the same newline-delimited <key>=<value> format as the libtuner section of the XML file. Note that, like the -u option, this option applies only to the current device.

-o <string> : Allows custom options to be supplied to the capture thread for the current device. The option string should be in the form of <key>=<value>;<key>=<value>;... --in other words, a semicolon-delimited version of the libtuner configuration format. In fact, libtuner configuration settings may be supplied using this option. Beyond any libtuner configuration settings, the following settings are currently recognized by the application: || Key || Default Value || Comments ||; || packet_delay || 100 || Specifies the number of packets to discard at the beginning of a capture or after a channel change. Applies only to MPEG TS devices. Depending on the tuner, the first few packets can have invalid payloads, which can cause problems for some decoders ||;