mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-14 13:21:28 +00:00
42 lines
2.3 KiB
Text
42 lines
2.3 KiB
Text
OUTDATED
|
|
--------
|
|
|
|
You might start by creating a source element and put it into a pipeline.
|
|
At this point both element's state would be GST_STATE_NEW, since they
|
|
don't have enough state to actually run yet. At this point you can set
|
|
the filename of the source, and possibly bytesperread and other things.
|
|
|
|
Then you'd want to discover the data type of the file you're sourcing.
|
|
This will typically be handled by the pipeline itself by calling
|
|
gst_pipeline_autoplug(), or gst_pipeline_find_pad_type(), or somesuch. The
|
|
pipeline would first set its state to GST_STATE_DISCOVERY. A gstfindtype
|
|
sink would be added to the pipeline and connected to the source. Its
|
|
HAVE_TYPE signal would be connected to a private pipeline function.
|
|
|
|
The pipeline would then set the the src state to GST_STATE_DISCOVERY, and
|
|
call the src's push() function until a the type is set by the function
|
|
connected to the gstfindtype element's signal. At this point the pipeline
|
|
would disconnect the gstfindtype element from the src, set the type of the
|
|
pad to the type returned by the gstfindtype element. At disconnection of
|
|
the find element, the src's state automatically reverts to NEW.
|
|
|
|
(The trick with the sources when they do DISCOVERY is that synchronous
|
|
sources can't go back and read data again. So perhaps I should set up a
|
|
wrapper function for the push() function that uses either a sync or
|
|
async function as provided by the src instance to provide DISCOVERY and
|
|
normal operations. It would use a [GstBufferCache] to read ahead into
|
|
memory if necessary, creating baby buffers as necessary to answer the
|
|
needs of each DISCOVERY sequence.)
|
|
|
|
If you called find_pad_type(), it would return right about now, with the
|
|
ID of the type it found. At the same time, if you have connected a signal
|
|
to the pad's SET_TYPE signal, it would fire right as the type is set by
|
|
the find_pad_type() function. This would allow your application to do its
|
|
own selection of filters to connect to the pad.
|
|
|
|
If you called autoplug(), the pipeline would make a selection of element
|
|
to connect. The element would be created (state=NEW), added to the
|
|
pipeline, and the appropriate sink pad connected to the src in question.
|
|
(Note that multi-sink elements won't be supported unless there's a really
|
|
good and obvious way to do so) The whole process would repeat until the
|
|
recently added element no longer has a src pad.
|