As noted in the foregoing, each GStreamer pipeline in the lag processing stage cannot, by itself, be a part of the backend system. The integration of a pipeline into the lag processing stage is accomplished by a GStreamer application that creates and manages the pipeline, and takes care of passing on messages posted to the pipeline message bus to the input stage. This application can create any GStreamer pipeline whose first element includes a sink pad that will accept lag sets. The pipeline created by the application automatically includes a wcbe_lagset_src source element at its head; that element should never be explicitly included in the pipeline specification passed to the application.

The application command line synopsis is

	Note
	It is additionally planned to support the use of a file of recorded lag sets as input (much like wcbe allows), but this feature has not yet been implemented. Being able to use lag sets from a file would be useful for the development and testing of new pipeline elements.

Note

The syntax of the pipeline description can be obtained from the gst-launch man page. It is uncertain whether this syntax for lag processing stage pipeline descriptions will satisfy all requirements or be efficient to use; although no real instances have yet been identified that could be used as an argument in support of changing the syntax, the possibility of a future change should not be discounted.

The application listens for application messages on the pipeline's message bus, and will forward upstream all such messages to the input stage. Messages are forwarded with a slightly changed src field value (which normally identifies the message's source element name) to include the name of the pipeline; this is done so that message handlers in the input stage can determine both the pipeline and the element that originated the message.

A GST_MESSAGE_EOS message posted on the pipeline's message bus will be received by the application, which will subsequently initiate its own termination.