Differences between revisions 2 and 3
Revision 2 as of 2008-11-27 13:14:29
Size: 948
Editor: localhost
Comment:
Revision 3 as of 2008-11-28 01:51:37
Size: 1607
Editor: AURORA
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
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. 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 not specified, the application will attempt to use ~/.cx88.xml.

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 not specified, the application will attempt to use ~/.cx88.xml.

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