Interface describing a collection of Valves that should be executed in sequence when the invoke() method is invoked. It is required that a Valve somewhere in the pipeline (usually the last one) must process the request and create the corresponding response, rather than trying to pass the request on.
There is generally a single Pipeline instance associated with each Container. The container's normal request processing functionality is generally encapsulated in a container-specific Valve, which should always be executed at the end of a pipeline. To facilitate this, the setBasic() method is provided to set the Valve instance that will always be executed last. Other Valves will be executed in the order that they were added, before the basic Valve is executed.
A pipeline expects one or more {@link PipelineComponent}s that passed by using {@link #addComponent(PipelineComponent)}. Then these components get linked with each other in the order they were added. The {@link #setup(OutputStream,Map)} method, calls the setup method on allpipeline components and assembles the pipeline. Finally the {@link #execute()} method produces the result and writes it to the{@link OutputStream} which has been passed to the{@link #setup(OutputStream,Map)} method.
A pipeline works based on two fundamental concepts:
When the pipeline links the components, it merely checks whether the above mentioned interfaces are present. So the pipeline does not know about the specific capabilities or the compatibility of the components. It is the responsibility of the {@link Producer} to decide whether a specific{@link Consumer} can be linked to it or not (that is, whether it can produceoutput in the desired format of the {@link Consumer} or not). It is alsoconceivable that a {@link Producer} is capable of accepting different typesof {@link Consumer}s and adjust the output format according to the actual {@link Consumer}.
This api is experimental and thus the classes and the interfaces returned are subject to change.
Elements are added and removed from the pipeline using the {@code Bin}methods like {@link Bin#add add} and {@link Bin#remove remove}.
Before changing the state of the Pipeline (see {@link Element}) a {@link Bus} can be retrieved with {@link #getBus getBus}. This bus can then be used to receive {@link Message}s from the elements in the pipeline.
By default, a Pipeline will automatically flush the pending Bus messages when going to the NULL state to ensure that no circular references exist when no messages are read from the Bus. This behaviour can be changed with {@link #setAutoFlushBus setAutoFlushBus}
When the Pipeline performs the PAUSED to PLAYING state change it will select a clock for the elements. The clock selection algorithm will by default select a clock provided by an element that is most upstream (closest to the source). For live pipelines (ones that return {@link StateChangeReturn#NO_PREROLL} from the {@link Element#setState setState} call) this will select the clock provided by the live source. For normal pipelines this will select a clock provided by the sinks (most likely the audio sink). If no element provides a clock, a default SystemClock is used.
The clock selection can be controlled with the gst_pipeline_use_clock() method, which will enforce a given clock on the pipeline. With gst_pipeline_auto_clock() the default clock selection algorithm can be restored.
A Pipeline maintains a stream time for the elements. The stream time is defined as the difference between the current clock time and the base time. When the pipeline goes to READY or a flushing seek is performed on it, the stream time is reset to 0. When the pipeline is set from PLAYING to PAUSED, the current clock time is sampled and used to configure the base time for the elements when the pipeline is set to PLAYING again. This default behaviour can be changed with the gst_pipeline_set_new_stream_time() method. When sending a flushing seek event to a GstPipeline (see {@link #seek seek}), it will make sure that the pipeline is properly PAUSED and resumed as well as set the new stream time to 0 when the seek succeeded.
Unlike the standard Piped* classes, Pipeline and its related classes do not try to detect dead pipes based on exit of threads. Instead, a pipeline shuts down when the sources are closed, or when {@link #shutdown()} method called.
The intended lifecycle of a Pipeline is as follows:
| |
| |
| |
| |