gstreamer/docs/random/walkthrough
Erik Walthinsen 0ec400890c initial checkin
Original commit message from CVS:
initial checkin
2000-01-30 10:44:33 +00:00

40 lines
2.3 KiB
Plaintext

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.