Ogg Vorbis is a completely open, patent-free, professional audio encoding and streaming technology
Copy-on-write (COW), sometimes referred to as implicit sharing[1] or shadowing,[2]
is a resource-management technique used in computer programming to efficiently implement a "duplicate" or "copy" operation on modifiable resources.[3]
If a resource is duplicated but not modified, it is not necessary to create a new resource; the resource can be shared between the copy and the original.
Modifications must still create a copy, hence the technique: the copy operation is deferred to the first write. By sharing resources in this way,
it is possible to significantly reduce the resource consumption of unmodified copies, while adding a small overhead to resource-modifying operations.

Pads are element‘s input and output, where you can connect other elements.
Pads have specific data handling capabilities,Data types are negotiated between pads using a process called caps negotiation
A bin is a container for a collection of elements
A pipeline is a top-level bin. It provides a bus for the application and manages the synchronization for its children

buffers are objects for passing streaming data between elements in the pipeline.
events are objects sent between elements or from the application to elements
messages are objects posted by elements on the pipeline‘s message bus
queries allow applications to request information such as duration or current playback position from the pipeline(always synchronous)

gst_init has to be called from the main application. This call will perform the necessary initialization of the library
A GstElement object is created from a factory.
gst-inspect
Element factories are the basic types retrieved from the GStreamer registry, they describe all plugins and elements that GStreamer can create
adding an element to a bin will disconnect any already existing links. Also, you cannot directly link elements that are not in the same bin or pipeline
When you set a bin or pipeline to a certain target state, it will usually propagate the state change to all elements within the bin or pipeline automatically
you add an element to will take ownership of that element. If you destroy the bin, the element will be dereferenced with it.
playbin and uridecodebin
A bus is a simple system that takes care of forwarding messages from the streaming threads to an application in its own thread context
pipeline: gstreamer will create at least one thread FOR Bus to pass message to appication
Caps are called simple caps when they contain only one structure, and fixed caps when they contain only one structure and have no variable field types
Events are control particles that are sent both up- and downstream in a pipeline along with buffers,Buffers contain the actual media data

Seeking is done using the concept of events
Querying is defined as requesting a specific stream property related to progress trackin

nternally, queries will be sent to the sinks, and “dispatched” backwards until one element can handle it

After the pipeline is prerolled, it will go back to the state (PAUSED or PLAYING)
prerolled()
The first is stream tags, which describe the content of a stream in a non-technical way. Examples include the author of a song, the title of that very same song or the album it is a part of.
The other type of metadata is stream-info, which is a somewhat technical description of the properties of a stream. This can include video size, audio samplerate, codecs used and so on.

Stream information can most easily be read by reading it from a GstPad. This has already been discussed before in Using capabilities for metadata. Therefore, we will skip it here.
Note that this requires access to all pads of which you want stream information.

Tag reading is done through a bus in GStreamer, which has been discussed previously in Bus. You can listen for GST_MESSAGE_TAG messages and handle them as you wish

GStreamer uses a GstClock object, buffer timestamps and a SEGMENT event to synchronize streams in a pipeline as we will see in the next sections.
Synchronization is now a matter of making sure that a buffer with a certain running-time is played when the clock reaches the same running-time.

Latency compensation
Before the pipeline goes to the PLAYING state, it will, in addition to selecting a clock and calculating a base-time, calculate the latency in the pipeline.
It does this by doing a LATENCY query on all the sinks in the pipeline. The pipeline then selects the maximum latency in the pipeline and configures this with a LATENCY event.

All sink elements will delay playback by the value in the LATENCY event. Since all sinks delay with the same amount of time, they will be relative in sync

he purpose of buffering is to accumulate enough data in a pipeline so that playback can occur smoothly and without interruptions
In the buffering state, the application should keep the pipeline in the PAUSED state

An element can, for example, choose to start a thread to start pulling from the sink pad or/and start pushing

What will happen in any case is that some elements will start a thread for their data processing, called the “streaming threads”. The streaming threads, or GstTask objects, are created from a GstTaskPool when the element needs to make a streaming thread

gstreamer