Differences between revisions 20 and 21
Revision 20 as of 2008-11-29 05:43:06
Size: 2626
Editor: localhost
Comment:
Revision 21 as of 2008-11-29 05:45:01
Size: 2627
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
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). 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).

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 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.

Overview/CaptureApp (last edited 2012-06-25 22:57:02 by jason)