# GStreamer

GStreamer is a pipeline-based multimedia framework that links together a wide variety of media processing systems to complete complex workflows. For instance, GStreamer can be used to build a system that reads files in one format, processes them, and exports them in another. The formats and processes can be changed in a plug and play fashion.
GStreamer supports a wide variety of media-handling components, including simple audio playback, audio and video playback, recording, streaming and editing. The pipeline design serves as a base to create many types of multimedia applications such as video editors, transcoders, streaming media broadcasters and media players.
It is designed to work on a variety of operating systems, e.g. the BSDs, OpenSolaris, Linux, Android, macOS, iOS, Windows, OS/400.
GStreamer is free and open-source software subject to the terms of the LGPL-2.1-or-later and is being hosted at freedesktop.org.

## Distribution and adoption

The GNOME desktop environment, a heavy user of GStreamer, has included GStreamer since GNOME version 2.2 and encourages GNOME and GTK applications to use it. Other projects also use or support it, such as the Phonon media framework and the Songbird media player. It is also used in the WebKit browser engine.
GStreamer also operates in embedded devices like the Jolla Phone, the Palm Pre, Tizen and the Nokia 770, N800, N810, N900 and N9 Internet Tablets running the Maemo operating system.
In addition to source code releases, the GStreamer project provides binary builds for Android, iOS, OSX and Windows.
The LIGO Laboratory make use of GStreamer to simulate and analyze gravitational wave data. The GStreamer interface is called GstLAL.

## Software architecture

GStreamer is written in the C programming language with the type system based on GObject and the GLib 2.0 object model.

### Language bindings

A library written in one programming language may be used in another language if bindings are written; GStreamer has a range of bindings for various languages such as Go, Python, Rust, Vala, C++, Perl, GNU Guile, C# and Ruby.

### Overview

GStreamer processes media by connecting a number of processing elements into a pipeline. Each element is provided by a plug-in. Elements can be grouped into bins, which can be further aggregated, thus forming a hierarchical graph. This is an example of a filter graph.
Elements communicate by means of pads. A source pad on one element can be connected to a sink pad on another. When the pipeline is in the playing state, data buffers flow from the source pad to the sink pad. Pads negotiate the kind of data that will be sent using capabilities.
The diagram to the right could exemplify playing an MP3 file using GStreamer. The file source reads an MP3 file from a computer's hard-drive and sends it to the MP3 decoder. The decoder decodes the file data and converts it into PCM samples which then pass to the sound-driver. The sound-driver sends the PCM sound samples to the computer's speakers.

### Plug-ins

GStreamer uses a plug-in architecture which makes the most of GStreamer's functionality implemented as shared libraries. GStreamer's base functionality contains functions for registering and loading plug-ins and for providing the fundamentals of all classes in the form of base classes. Plug-in libraries get dynamically loaded to support a wide spectrum of codecs, container formats, input/output drivers and effects.
Plug-ins can be installed semi-automatically when they are first needed. For that purpose distributions can register a backend that resolves feature-descriptions to package-names.
Since version 0.9, the plug-ins come grouped into three sets (named after the film The Good, the Bad and the Ugly).
| Plug-in set name | Description |
| Good | This package contains the GStreamer plug-ins from the "good" set, a set of high quality plug-ins under the LGPL license. |
| Bad | GStreamer Bad Plug-ins comprises a set of plug-ins not up-to-par compared to the rest. They might closely approach good-quality plug-ins, but they lack something: perhaps a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use. |
| Ugly | This package contains plug-ins from the "ugly" set, a set of good-quality plug-ins that might pose distribution problems. |
Individual distributions may further sub-classify these plug-ins: for example Ubuntu groups the "bad" and "ugly" sets into the "Universe" or the "Multiverse" components.
In addition, there is a GStreamer FFmpeg plug-in (called gst-libav for historic reasons) that extends the number of supported media formats.

#### Video acceleration

There are various SIP blocks that can do the computations to decode certain video codecs, such as PureVideo, UVD, QuickSync Video, TI Ducati and more. Such needs to be supported by the device driver, which in turn provides one or multiple interfaces, like VDPAU, VAAPI, Distributed Codec Engine or DXVA to end-user software like MPlayer to access this hardware and offload computation to it.
* It is possible to use Video Coding Engine with GStreamer through the OpenMAX IL wrapper plugin gst-omx. This is for example possible on the Raspberry Pi.
* The SIP core present on some Texas Instruments SoCs is also accessible through GStreamer: gst-dmai, gst-openmax, gst-dsp.
* VDPAU and VAAPI are supported with GNOME Videos >= 2.28.0 and GStreamer >= 0.10.26 since 2010
* Broadcom Crystal HD is supported

#### Media formats

The Good, Bad and Ugly GStreamer plugins mentioned earlier provide, alongside processing elements/filters of all kinds, support for a wide variety of file formats, protocols and multimedia codecs. In addition to those, support for more than a hundred compression formats (including MPEG-1, MPEG-2, MPEG-4, H.261, H.263, H.264, RealVideo, MP3, WMV, etc.) is transparently provided through the gst-libav plug-in.

## History and development
### Early days

Erik Walthinsen founded the GStreamer project in 1999. Many of its core design ideas came from a research project at the Oregon Graduate Institute. Wim Taymans joined the project soon thereafter and greatly expanded on many aspects of the system. Many other software developers have contributed since then.
The first major release was 0.1.0 which was announced on 11 January 2001. Not long after, GStreamer picked up its first commercial backer. Towards the end of January 2001, they hired Erik Walthinsen to develop methods for embedding GStreamer in smaller (cell phone-class) devices. Another RidgeRun employee, Brock A. Frazier, designed the GStreamer logo. RidgeRun later struggled financially and had to lay off its staff, including Erik Walthinsen. GStreamer progress was mostly unaffected.
The project released a series of major releases with 0.2.0 coming out in July 2001, 0.4.0 in September 2002, and 0.8.0 in March 2004. During that period the project also changed its versioning strategy and while the first releases were simply new versions, later on the middle number started signifying release series. This meant the project did release a string of 0.6.x and 0.8.x releases which was meant to stay binary compatible within those release series. Erik Walthinsen more or less left GStreamer development behind during this time, focusing on other ventures.
All release series, the project face difficulties. Every series is not very popular in the Linux community mostly because of stability issues and a serious lack of features compared to competing projects like Xine, MPlayer, and VLC. The project also suffers a lack of leadership as Wim Taymans, the project lead since Erik Walthinsen had left, had largely stopped participating.

### The 0.10 series

In 2004, a new company was founded, Fluendo, which wanted to use GStreamer to write a streaming server Flumotion and also provide multimedia solutions for GStreamer. During this time, Fluendo hired most of the core developers including Wim Taymans and attracted the support of companies such as Nokia and Intel to bring GStreamer to a professional level and drive community adoption.
With Wim Taymans back at the helm, the core of GStreamer was redesigned and became what is the current 0.10.x series, which had its first release (0.10.0) in December 2005. It has maintained API and ABI compatibility since.
With a new stable core in place, GStreamer gained in popularity in 2006, being used by media players including Totem, Rhythmbox and Banshee with many more to follow. It was also adopted by corporations such as Nokia, Motorola, Texas Instruments, Freescale, Tandberg, and Intel.
In 2007, most of the core GStreamer developers left Fluendo, including GStreamer maintainer Wim Taymans who went on to co-found Collabora Multimedia together with other GStreamer veterans, while others joined Sun Microsystems, Oblong Industries, and Songbird.
Between June 2012 and August 2014, GStreamer 0.10 was also distributed by Collabora and Fluendo as a multiplatform SDK, on the third-party gstreamer.com website (rather than gstreamer.freedesktop.org for the upstream community project). The goal was to provide application developers with a SDK that would be functionally identical on Windows, Mac OS X, iOS, and Android. The SDK initiative aimed to facilitate the commercial adoption of the GStreamer project, as it provided a standardized entry point to developing multimedia applications with GStreamer, without needing to build the entire platform by oneself. Users of the SDK also benefited from documentation Archived 2012-06-16 at the Wayback Machine, tutorials and instructions specific to that SDK.

### The 1.x series

GStreamer 1.0 was released on September 24, 2012. The 1.x series is parallel installable to GStreamer 0.10 to ease the transition, and provides many architectural advantages over the 0.10 series. Generally speaking, GStreamer 1.0 brought significant improvements for:
* Embedded processors support, lower power consumption, offloading work to specialized hardware units (such as DSPs)
* Hardware accelerated video decoding/encoding using GPUs
* Zero-copy memory management (avoiding unnecessary roundtrips between the CPU and GPU) for better performance and lower power consumption
* Dynamic pipelines
* API and code cleanups
Beyond the technical improvements, the 1.x series is also defined by a new release versioning scheme. As the GStreamer roadmap explains, all 1.x.y versions carry a -1.0 API version suffix and have a stable API/ABI. The API/ABI can only be broken by a new major release series (i.e.: 2.x); however, there are currently no plans for a 2.0 release series. Until then, the new version numbering scheme can be used to predict the intended use of each release. The roadmap cites some examples:
* 1.0.0, 1.0.1, 1.0.2, 1.0.3... stable release and follow-up bug-fix releases
* 1.1.0, 1.1.1, 1.1.2, 1.1.3... pre-releases, development version leading up to 1.2.0
* 1.2.0, 1.2.1, 1.2.2, 1.2.3... stable release and follow-up bug-fix releases
* 1.3.0...
* 1.4.0...
* etc.
In March 2013, the GStreamer project maintainers issued a statement to clarify that the 0.10 series is no longer maintained. The statement reasserted the GStreamer project's willingness to help application and plugin developers migrate to the new technology, and hinted that those for whom switching to the 1.x series was still considered impossible could seek assistance from various consulting companies.
1.2 added support for DASH adaptive streaming, JPEG 2000 images, VP9 and Daala video, and decoding-only support for WebP.
Version 1.14 was released on March 19, 2018, adding support for WebRTC, AV1, Nvidia NVDEC, and Secure Reliable Transport, among other changes.
Version 1.22 was released on January 23, 2023, adding improved support for AV1, in addition to support for HLS, DASH and Microsoft Smooth Streaming for adaptive bitrate streaming.