Commits (4053)

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -8,7 +8,6 @@ config.guess
......@@ -44,6 +43,7 @@ Makefile
......@@ -51,7 +51,7 @@ Makefile
......@@ -69,3 +69,6 @@ Build
[submodule "common"]
path = common
url = git://anongit.freedesktop.org/gstreamer/common
url = https://anongit.freedesktop.org/git/gstreamer/common.git
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -28,13 +28,13 @@ DIST_SUBDIRS = \
common \
# include before EXTRA_DIST for win32 assignment
include $(top_srcdir)/common/win32.mak
gst-plugins-base.spec depcomp \
ChangeLog gst-plugins-base.doap autogen.sh $(win32)
depcomp \
ChangeLog gst-plugins-base.doap autogen.sh \
$(shell find "$(top_srcdir)" -type f -name meson.build ! -path "$(top_srcdir)/$(PACKAGE_TARNAME)-*" ) \
gst-libs/gst/gl/gstglconfig.h.meson \
......@@ -58,29 +58,18 @@ build-checks:
WIN32_COPY = \
$(top_builddir)/gst-libs/gst/*/*-enumtypes.[ch] \
for f in $(WIN32_COPY); do cp -v $$f win32/common; done; \
for f in win32/common/*-enumtypes.c; do \
echo "Indenting $$f"; \
gst-indent $$f; gst-indent $$f; \
cp -v $(top_builddir)/win32/common/config.h-new \
include $(top_srcdir)/common/coverage/lcov.mak
check: check-exports
# cruft: plugins that have been merged or moved or renamed
$(top_builddir)/gst-plugins-base.spec \
$(top_builddir)/common/shave \
$(top_builddir)/common/shave-libtool \
$(top_builddir)/gst-libs/gst/audio/testchannels \
$(top_builddir)/gst-libs/gst/app/gstapp-marshal.c \
$(top_builddir)/gst-libs/gst/app/gstapp-marshal.h \
$(top_builddir)/gst/encoding/.libs/libgstencodebin.so \
$(top_builddir)/tests/check/elements/gdppay \
$(top_builddir)/tests/check/elements/gdpdepay \
$(top_builddir)/tests/check/pipelines/streamheader \
......@@ -89,10 +78,12 @@ CRUFT_FILES = \
$(top_srcdir)/docs/design \
$(top_srcdir)/docs/plugins/tmpl \
$(top_srcdir)/ext/gio \
$(top_srcdir)/gst/gdp \
$(top_srcdir)/sys/v4l \
$(top_srcdir)/win32 \
include $(top_srcdir)/common/cruft.mak
This diff is collapsed.
GStreamer 1.7.x development series
GStreamer 1.15.x development series
This is GStreamer gst-plugins-base
Release notes for GStreamer Base Plugins 1.8.0
GStreamer 1.15 is the development version leading up to the next major
stable version which will be 1.16.
The GStreamer team is pleased to announce the first release of the new stable
1.8 release series. The 1.8 release series is adding new features on top of
the 1.0, 1.2, 1.4 and 1.6 series and is part of the API and ABI-stable 1.x
release series of the GStreamer multimedia framework.
The 1.15 development series adds new features on top of the 1.14 series and is
part of the API and ABI-stable 1.x release series of the GStreamer multimedia
Full release notes will one day be found at:
Binaries for Android, iOS, Mac OS X and Windows will be provided shortly after
the source release by the GStreamer project during the stable 1.8 release
Binaries for Android, iOS, Mac OS X and Windows will be provided shortly
after the release.
This module contains a set of reference plugins, base classes for other
plugins, and helper libraries. It also includes essential elements such
as audio and video format converters, and higher-level components like playbin,
decodebin, encodebin, and discoverer.
This module will not be very useful by itself and should be used in conjunction
with other GStreamer modules for a complete multimedia experience.
This module is kept up-to-date together with the core developments. Element
writers should look at the elements in this module as a reference for
their development.
- gstreamer: provides the core GStreamer libraries and some generic plugins
This module contains elements for, among others:
- gst-plugins-base: a basic set of well-supported plugins and additional
media-specific GStreamer helper libraries for audio,
video, rtsp, rtp, tags, OpenGL, etc.
device plugins: x(v)imagesink, alsa, v4lsrc, cdparanoia
containers: ogg
codecs: vorbis, theora
text: textoverlay, subparse
sources: audiotestsrc, videotestsrc, giosrc
network: tcp
typefind functions
audio processing: audioconvert, adder, audiorate, audioresample, volume
visualisation: libvisual
video processing: videoconvert, videoscale
high-level components: playbin, uridecodebin, decodebin, encodebin, discoverer
libraries: app, audio, fft, pbutils, riff, rtp, rtsp, sdp, tag, video
- gst-plugins-good: a set of well-supported plugins under our preferred
- gst-plugins-ugly: a set of well-supported plugins which might pose
problems for distributors
Other modules containing plugins are:
- gst-plugins-bad: a set of plugins of varying quality that have not made
their way into one of core/base/good/ugly yet, for one
reason or another. Many of these are are production quality
elements, but may still be missing documentation or unit
tests; others haven't passed the rigorous quality testing
we expect yet.
- gst-libav: a set of codecs plugins based on the ffmpeg library. This is
where you can find audio and video decoders and encoders
for a wide variety of formats including H.264, AAC, etc.
contains a set of well-supported plugins under our preferred license
contains a set of well-supported plugins, but might pose problems for
contains a set of less supported plugins that haven't passed the
rigorous quality testing we expect, or are still missing documentation
and/or unit tests
contains a set of codecs plugins based on libav (formerly gst-ffmpeg)
- gstreamer-vaapi: hardware-accelerated video decoding and encoding using
VA-API on Linux. Primarily for Intel graphics hardware.
- gst-omx: hardware-accelerated video decoding and encoding, primarily for
embedded Linux systems that provide an OpenMax
implementation layer such as the Raspberry Pi.
- gst-rtsp-server: library to serve files or streaming pipelines via RTSP
Bugs fixed in this release
* 763316 : install-plugins: update documentation
- gst-editing-services: library an plugins for non-linear editing
==== Download ====
You can find source releases of gst-plugins-base in the download
directory: https://gstreamer.freedesktop.org/src/gst-plugins-base/
You can find source releases of gstreamer in the download
directory: https://gstreamer.freedesktop.org/src/gstreamer/
The git repository and details how to clone it can be found at
==== Homepage ====
......@@ -91,9 +82,3 @@ from there (see link above).
Interested developers of the core library, plugins, and applications should
subscribe to the gstreamer-devel list.
Contributors to this release
* Víctor Manuel Jáquez Leal
\ No newline at end of file
......@@ -53,7 +53,7 @@ fi
CONFIGURE_DEF_OPT='--enable-maintainer-mode --enable-gtk-doc'
if test "x$package" = "xgstreamer"; then
CONFIGURE_DEF_OPT="$CONFIGURE_DEF_OPT --enable-docbook --enable-failing-tests --enable-poisoning"
CONFIGURE_DEF_OPT="$CONFIGURE_DEF_OPT --enable-failing-tests --enable-poisoning"
elif test "x$package" = "xgst-plugins-bad"; then
common @ cd1dee06
Subproject commit 6f2d2093e84cc0eb99b634fa281822ebb9507285
Subproject commit cd1dee06bf07f094677d0cf3eea4a2e8c2636b24
This diff is collapsed.
......@@ -8,8 +8,8 @@ else
DIST_SUBDIRS = design libs plugins
DIST_SUBDIRS = libs plugins
design-audiosinks.txt \
design-decodebin.txt \
design-encoding.txt \
design-orc-integration.txt \
draft-hw-acceleration.txt \
draft-keyframe-force.txt \
draft-va.txt \
part-interlaced-video.txt \
Audiosink design
- must operate chain based.
Most simple playback pipelines will push audio from the decoders
into the audio sink.
- must operate getrange based
Most professional audio applications will operate in a mode where
the audio sink pulls samples from the pipeline. This is typically
done in a callback from the audiosink requesting N samples. The
callback is either scheduled from a thread or from an interrupt
from the audio hardware device.
- Exact sample accurate clocks.
the audiosink must be able to provide a clock that is sample
accurate even if samples are dropped or when discontinuities are
found in the stream.
- Exact timing of playback.
The audiosink must be able to play samples at their exact times.
- use DMA access when possible.
When the hardware can do DMA we should use it. This should also
work over bufferpools to avoid data copying to/from kernel space.
The design is based on a set of base classes and the concept of a
ringbuffer of samples.
+-----------+ - provide preroll, rendering, timing
+ basesink + - caps nego
+-----V----------+ - manages ringbuffer
+ audiobasesink + - manages scheduling (push/pull)
+-----+----------+ - manages clock/query/seek
| - manages scheduling of samples in the ringbuffer
| - manages caps parsing
+-----V------+ - default ringbuffer implementation with a GThread
+ audiosink + - subclasses provide open/read/close methods
The ringbuffer is a contiguous piece of memory divided into segtotal
pieces of segments. Each segment has segsize bytes.
play position
+ 0 | 1 | 2 | .... | segtotal |
segsize bytes = N samples * bytes_per_sample.
The ringbuffer has a play position, which is expressed in
segments. The play position is where the device is currently reading
samples from the buffer.
The ringbuffer can be put to the PLAYING or STOPPED state.
In the STOPPED state no samples are played to the device and the play
pointer does not advance.
In the PLAYING state samples are written to the device and the ringbuffer
should call a configurable callback after each segment is written to the
device. In this state the play pointer is advanced after each segment is
A write operation to the ringbuffer will put new samples in the ringbuffer.
If there is not enough space in the ringbuffer, the write operation will
block. The playback of the buffer never stops, even if the buffer is
empty. When the buffer is empty, silence is played by the device.
The ringbuffer is implemented with lockfree atomic operations, especially
on the reading side so that low-latency operations are possible.
Whenever new samples are to be put into the ringbuffer, the position of the
read pointer is taken. The required write position is taken and the diff
is made between the required and actual position. If the difference is <0,
the sample is too late. If the difference is bigger than segtotal, the
writing part has to wait for the play pointer to advance.
- chain based mode:
In chain based mode, bytes are written into the ringbuffer. This operation
will eventually block when the ringbuffer is filled.
When no samples arrive in time, the ringbuffer will play silence. Each
buffer that arrives will be placed into the ringbuffer at the correct
times. This means that dropping samples or inserting silence is done
automatically and very accurate and independend of the play pointer.
In this mode, the ringbuffer is usually kept as full as possible. When
using a small buffer (small segsize and segtotal), the latency for audio
to start from the sink to when it is played can be kept low but at least
one context switch has to be made between read and write.
- getrange based mode
In getrange based mode, the audiobasesink will use the callback function
of the ringbuffer to get a segsize samples from the peer element. These
samples will then be placed in the ringbuffer at the next play position.
It is assumed that the getrange function returns fast enough to fill the
ringbuffer before the play pointer reaches the write pointer.
In this mode, the ringbuffer is usually kept as empty as possible. There
is no context switch needed between the elements that create the samples
and the actual writing of the samples to the device.
DMA mode:
- Elements that can do DMA based access to the audio device have to subclass
from the GstAudioBaseSink class and wrap the DMA ringbuffer in a subclass
of GstRingBuffer.
The ringbuffer subclass should trigger a callback after writing or playing
each sample to the device. This callback can be triggered from a thread or
from a signal from the audio device.
The GstAudioBaseSink class will use the ringbuffer to act as a clock provider.
It can do this by using the play pointer and the delay to calculate the
clock time.
This diff is collapsed.
This diff is collapsed.
Orc Integration
- About Orc
- Fast memcpy()
- Normal Usage
- Build Process
- Testing
- Orc Limitations
About Orc
Orc code can be in one of two forms: in .orc files that is converted
by orcc to C code that calls liborc functions, or C code that calls
liborc to create complex operations at runtime. The former is mostly
for functions with predetermined functionality. The latter is for
functionality that is determined at runtime, where writing .orc
functions for all combinations would be prohibitive. Orc also has
a fast memcpy and memset which are useful independently.
Fast memcpy()
*** This part is not integrated yet. ***
Orc has built-in functions orc_memcpy() and orc_memset() that work
like memcpy() and memset(). These are meant for large copies only.
A reasonable cutoff for using orc_memcpy() instead of memcpy() is
if the number of bytes is generally greater than 100. DO NOT use
orc_memcpy() if the typical is size is less than 20 bytes, especially
if the size is known at compile time, as these cases are inlined by
the compiler.
(Example: sys/ximage/ximagesink.c)
Add $(ORC_CFLAGS) to libgstximagesink_la_CFLAGS and $(ORC_LIBS) to
libgstximagesink_la_LIBADD. Then, in the source file, add:
#ifdef HAVE_ORC
#include <orc/orc.h>
#define orc_memcpy(a,b,c) memcpy(a,b,c)
Then switch relevant uses of memcpy() to orc_memcpy().
The above example works whether or not Orc is enabled at compile
Normal Usage
The following lines are added near the top of Makefile.am for plugins
that use Orc code in .orc files (this is for the volume plugin):
include $(top_srcdir)/common/orc.mk
Also add the generated source file to the plugin build:
nodist_libgstvolume_la_SOURCES = $(ORC_SOURCES)
And of course, add $(ORC_CFLAGS) to libgstvolume_la_CFLAGS, and
$(ORC_LIBS) to libgstvolume_la_LIBADD.
The value assigned to ORC_BASE does not need to be related to
the name of the plugin.
Advanced Usage
The Holy Grail of Orc usage is to programmatically generate Orc code
at runtime, have liborc compile it into binary code at runtime, and
then execute this code. Currently, the best example of this is in
Schroedinger. An example of how this would be used is audioconvert:
given an input format, channel position manipulation, dithering and
quantizing configuration, and output format, a Orc code generator