is an extensive
support library for the creation of multimedia applications. Audio and
video applications can be constructed as a series of pipelines; there are
graphical tools which can be used to help put all of the pieces together in
the right order. GStreamer has been used as the back end for a number of
common applications, including Totem, Amarok, Banshee, and many others.
The project recently celebrated the release of GStreamer 0.10
which improves the system in a number of ways.
According to GStreamer hacker Christian Schaller, future releases of
GStreamer may contain a feature which is less welcome to many: digital restrictions
management (DRM) support. There are, says Mr. Schaller, clear
reasons why one might want to support DRM-enabled GStreamer modules:
Because they give you access to playback things you wouldn't
otherwise. Many music stores only offers DRM'ed WMA files for
download, and without a system supporting Windows DRM these files
are useless on your Linux system. DRM also includes stuff such as
the protection mechanism on the upcoming high-definition DVD's.
It appears that any DRM features would be packaged into separate modules,
making it easy to install a DRM-free GStreamer in the future.
Distributions could put the DRM modules into a separate package - or leave
them out entirely. So, it is claimed, the implementation of DRM in
GStreamer would not place any restrictions on current or future uses of the
Some skepticism on this claim would appear to be warranted. Any DRM module
which is to gain the trust of the entertainment industry (much less avoid
DMCA suits) will have to prevent the user from capturing an unencrypted
stream. To that end, GStreamer will have to be able to create "secure
pipelines"; DRM modules will then refuse to connect to modules which cannot
be "trusted" with protected content. If GStreamer is to retain its current
power and flexibility, many of its standard modules - and certainly those
concerned with the actual playing and display of media - will have to be
reworked to participate in secure pipelines. Either that, or significant
parts of the GStreamer will have to be duplicated in a "secure" mode. It
is hard to see how the entire GStreamer pipeline could be made to be secure
without affecting people who have no interest in DRM-enabled content.
There is also the obvious question of how DRM can be done securely in an
environment where source is available. Mr. Schaller points at Sun's "Opera" project as a
possible example of how things could be done, and notes:
There might be some ramifications of being free software which will
make the resulting system have conditions for use that makes it
painful, like a requirement for being online when playing back as
an example, but its definitely not impossible.
Still, anybody who can hack on the source can obtain an unencrypted stream
from a GStreamer DRM module. So it seems clear that such modules are
expected to be shipped in a binary-only mode. Even then, though, one
should remember that the Linux kernel is free software too. So even if the
GStreamer pipeline is entirely secure and uncrackable, a quick kernel hack
will still make the capturing of unrestricted streams easy. That suggests,
in turn, that the people looking to put DRM code into GStreamer envision
operating in environments where users cannot install their own kernels.
The TPM chips being put into an increasing number of computers may make
that kind of restriction possible, but the real target is probably
elsewhere: embedded systems.
The use of GStreamer to make non-hackable, Linux-based media gadgets will
be nothing new; various companies are creating such devices now. But the
incorporation of DRM capabilities into our free system seems like a step in
the wrong direction. Features like secure pipelines represent a loss of
control over our own systems - the very control that drives many of use to
use free software in the first place. So users and distributors may want
to think long and hard before allowing DRM-enabled GStreamer near their
to post comments)