Gstreamer 插件編寫【二】進階特性

一、Request and Sometimes pads：

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-advanced-request.html 參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-reqpad-request.html

二、Different scheduling modes：（Push mode and pull mode）

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-scheduling.html

三、Pads driving the pipeline：

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-scheduling-loop.html

四、Providing random access：

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-scheduling-randomxs.html

五、Caps negotiation：

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-negotiation.html

Implementing a CAPS query function：

參考：http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-nego-getcaps.html

六、Memory allocation（GstBuffer）：

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-allocation-buffer.html

七、Typefind：

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-types-typefind.html

集中所有的container 類型的檢測實作都在gsttypefindfunction.c函數中，如果放在每個plugin中實作類型檢測的話，需要一開始就加載所有的插件

八、Event：

downstream event: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-advanced-events.html

upstream event: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-events-upstream.html

All Events Together

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-events-definitions.html

九、tagging(Metadata and Streaminfo)：

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-advanced-tagging.html

Tags are pieces of information stored in a stream that are not the content itself, but they rather describe the content. Most media container formats support tagging in one way or another. Ogg uses VorbisComment for this, MP3 uses ID3, AVI and WAV use RIFF's INFO list chunk, etc. GStreamer provides a general way for elements to read tags from the stream and expose this to the user. The tags (at least the metadata) will be part of the stream inside the pipeline. The consequence of this is that transcoding of files from one format to another will automatically preserve tags, as long as the input and output format elements both support tagging.

Tags are separated in two categories in GStreamer, even though applications won't notice anything of this. The first are called metadata, the second are called streaminfo. Metadata are tags that describe the non-technical parts of stream content. They can be changed without needing to re-encode the stream completely. Examples are “author”,“title” or “album”. The container format might still need to be re-written for the tags to fit in, though. Streaminfo, on the other hand, are tags that describe the stream contents technically. To change them, the stream needs to be re-encoded. Examples are “codec” or “bitrate”. Note that some container formats (like ID3) store various streaminfo tags as metadata in the file container, which means that they can be changed so that they don't match the content in the file any more. Still, they are called metadata because technically, they can be changed without re-encoding the whole stream, even though that makes them invalid. Files with such metadata tags will have the same tag twice: once as metadata, once as streaminfo.

There is no special name for tag reading elements in GStreamer. There are specialised elements (e.g. id3demux) that do nothing besides tag reading, but any GStreamer element may extract tags while processing data, and most decoders, demuxers and parsers do.

A tag writer is called 

TagSetter

. An element supporting both can be used in a tag editor for quick tag changing (note: in-place tag editing is still poorly supported at the time of writing and usually requires tag extraction/stripping and remuxing of the stream with new tags).