GStreamer

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 Python, Rust, Vala, C++, Perl, GNU Guile, C# and Ruby.

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 ALSA sound-driver. The ALSA sound-driver sends the PCM sound samples to the computer's speakers.

GStreamer uses a plug-in architecture which makes the most of GStreamer's functionality implemented as shared libraries.[9] 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).[10]

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.

There's also a separate GStreamer FFmpeg plug-in, which is a FFmpeg-based plug-in that supports many additional media formats. It was first released on 26 February 2004, with version number 0.7.1.[14][15] It can transparently use Libav, and as such is often called the GStreamer Libav plug-in in recent Linux distributions.

Through special plugins provided by Texas Instruments, GStreamer makes use of hardware acceleration provided by e.g. Texas Instruments DaVinci.

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.[16] This is for example possible on the Raspberry Pi.[17]
• The SIP core present on some Texas Instruments SoCs is also accessible through GStreamer: gst-dmai, gst-openmax, gst-dsp.[18]
• VDPAU and VAAPI are supported with GNOME Videos >= 2.28.0 and GStreamer >= 0.10.26 since 2010[19]
• Broadcom Crystal HD is supported[20]

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.[21][22]) is transparently provided through the GStreamer FFmpeg/libav plug-in. See the Libav and FFmpeg pages for a complete list of media formats provided by these plug-ins.

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.[1] Not long after, GStreamer picked up its first commercial backer, an embedded Linux company called RidgeRun. 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.

During the 0.8.x release series, the project faced difficulties. The 0.8.x series was 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 suffered a lack of leadership as Wim Taymans, the project lead since Erik Walthinsen had left, had largely stopped participating.

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.[23] 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,[24] 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, Android and all supported Linux platforms. 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, tutorials and instructions specific to that SDK.

GStreamer 1.0 was released on September 24, 2012.[25] 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.[26] 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,[27] 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[28] 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, JPEG2000 images, VP9 and Daala video, and decoding-only support for WebP.

Version 1.14 was released on March 19, 2018,[29] adding support for WebRTC, AV1, Nvidia NVDEC, and Secure Reliable Transport, among other changes.