[gst-devel] Newbie questions: specialised source and sink plugins or not? etc

[John Murdie]

I'm looking again at gstreamer, hoping that it will be ideal for
rejuvenating sound support in a GUI application program which currently
uses SGI's (old but open source) dmSDK. I've been given lots of AIFF
files which the program should play. The obvious approach seemed to be
to use gstreamer's afsrc plugin, but gst-inspect shows no indication
that it has a seek capability (yet?) - and I need this. I found it easy
to make and test a (seeking) 'filesrc | mad | alsasink' pipeline. I
wonder whether specialised source and sink plugins (e.g. afsrc, afsink)
are preferred, or are not preferred, over the use of a general source
plugin (filesrc) followed by a filter decoder (e.g. mad). Should there
really be audiofile decoder and encoder plugins instead of afsrc and
afsink? Is there ever a case where specialised source and sink plugins
are imperative? Why did the author(s) of afsrc/afsink not choose to
write 'afdec' and 'afenc' instead?

I don't understand seeking in general; I can see how e.g. a file source
plugin can be made to seek - except that in my example pipeline above I
found it necessary to make 'mad' seek (backwards and forwards), as I
couldn't make filesrc seek (in bytes) - gst_element_seek(filesrc, ...)
keeps returning false. (In any case, I wish eventually to seek in time,
and for that I need to command the decoder to seek.) When I command
'mad' to seek, is a message passed back along the pipeline from 'mad' to
command filesrc to seek?

By the way, something I don't find in the Application Development Manual
(0.8.3.3); what does a '*parse' plugin do? (I understand the general
computer science meaning of the word, but what does it mean in a
multimedia pipeline context?) Is it simply a (programmable?) recogniser
for certain (specified) waveforms?

John A. Murdie