<nettime> streaming digest [adam, recktenwald]

["nettime's_digestive_system" <nettime@bbs.thing.net>]

Re: <nettime> streaming media software for arts released
     adam <adam@xs4all.nl>
     Heiko Recktenwald <uzs106@ibm.rhrz.uni-bonn.de>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Date: Sat, 23 Nov 2002 12:13:42 +0100 (CET)
From: adam <adam@xs4all.nl>
Subject: Re: <nettime> streaming media software for arts released

Hi,

I saw the text by Heiko and thought I would reply with a few comments. The
Frequency Clock is an open source (GPL) system for managing streaming
content which was developed by r a d i o q u a l i a (an artist group of which i am a part)
.

> > Perhaps the most significant and innovative element of the system is the
> > Frequency Clock Player. The Player addresses one of the key issues that
> > producers of streaming media face - the range of different streaming media
> > formats. Streaming media content can be produced in a variety of different
> > proprietary formats - for example, WindowsMedia, Real, and Quicktime. When
> > users play a streaming media file, it opens within a specific streaming
> > media player. If you watch a WindowsMedia file, it opens in the
> > WindowsMedia player, a Real file opens within the Real Player and so on.
> > Users must open and close a number of players in order to view different
> > streaming media formats. This can be disruptive to the continuity of the
> > experience.
>
> If you offer your content embeded in a webpage, you dont see much
> differences in design anymore. Most content is presented today in this way
> and you dont see anymore which plugin is acting.

Isnt this a good thing? I am not sure what your point is here, maybe it is
important to you to see the codec of the content but I am not sure why. In
terms of developing content this might be useful (the codec used can
always be known by looking at the source of the html) but I am pretty sure
most users don't care what codec content is made in until they discover
they dont have the right codecs installed.

However the point of this software system - the Frequency Clock - (A point
you touch on below) is
that we should be very much aware that most audio and video content on the
web is encoded by proprietary codecs. WindowsMedia, Real, QuickTime all
use proprietary codecs including MP3. This means that almost all content
encoded for artistic, cultural or independent media purposes is encrypted.
Encrypted in the sense that the content has been converted to a closed file format which can only be 'decrypted' by media players
that have the requisite licenced algorithms. Hence the owners of these
algorithms (Thompson and Fraunhofer, Microsoft, Real Networks etc) own the
key, its not a public key, its a closed proprietry key. You, the content
producer, cannot unlock this encrypted file unless you do
so with the appropriate media player software usually  created by the
software house that owns the codec.

This may seem ok now. As Heiko says later
"mp3s are patented etcpp, this was and is no problem in reality.". However
is it enough to trust that all will always be ok. Not discounting that
closed codecs might cause problems in the very near future, just consider
if you have encoded (encrypted) some video content with a closed codec
(lets tajke RealNetworks audio and video codecs for this example).
For now you might have the key (algorithm) to 'unlock' the content and
replay it in a media player (in this case the RealPlayer). However we can easily imagine
a situation in X years time where Real has crashed and burned and are no
longer a technology provider. Where is your content now? Your content
could well be in a encrypted file format with no licenced keys to open it.
The codec may have gone down with the company and you may be left begging
users to download the older players that you have found in some arcane
archive somewhere on the net, and who is to say the legal remains of (in
this case) RealNetworks won't stop you from doing even that?. Distributing
the software or its components (dlls / plugins etc) is illegal unless you
have express permission from RealNetworks in this example and the right to
stop you doing this my persist long after the companies death.

There is an interesting parallel to this with MAMEs (Multi-Arcade Machine
Emulators). Arcade games from of all sorts, going right back to PONG, are
available on the internet for download. However you require a software
known as a MAME to interpret the file formats of these games, there are
many of these emulators available but almost no more games (known as ROMS)
can be retrieved easily from the net unless you know exactly where to go. This is different
from a few years ago when you could easily get almost any ROM you wanted.
However these sites have been systematically closed down by games
companies protecting their interests. Many of the games companies that
created the original ROMS have ceased to exist but the ROMS are now owned
by other companies, and these new owners protect their
interests by closing MAME ROM sites.

Could this happen with codecs?

Its strange that this debate does not often enter the rosy world of the
'Open Source' idealists. Strangely Eric Raymond, president and co-founder
of the Open Source Initiative, has a speech about The Cathedral and the
Bazaar linked from his site in realaudio format
(http://tuxedo.org/~esr/writings/cathedral-bazaar/). This on the same site
that he points out that "Unisys is shaking down websites that use GIFs for
a $5000 license fee" and links to the well known http://burnallgifs.org/

Why is this medium (online audio / video) not debated more often in the
area of 'Open Source'?

It seems the potential consequences of closed and /or proprietry codecs
have only dawned on a few, most importantly those at http://xiph.org where
the development of the the royalty free ogg audio codec takes place and
http://www.theora.org/ where the same people are trying to develop the VP3
open video codec.

So what can we do about this? Well, if you are a programmer and have some
time on your hands then you can contribute to the many projects aimed at
countering the major technology providers in this field. One action could
be to contribute to the sophisticated Icecast open streaming server
project, or the various xiph projects. But most of us aren't that
technical and don't have that much time. The biggest thing we can do is
understand the issues, support those 'fighting the good fight' and prepare
to convert our archives from proprietry codecs to 'fully open' (from the
description of Ogg Vorbis (http://www.xiph.org/ogg/index.html) codecs. Its
getting easier to do this, many players (not just those on Linux platforms
but also popular players like Winamp) support OggVorbis already and the
list of supporting softwares for these free codecs is growing.

Another strategy, and to bring the point back to what Heiko says, is the
strategy adopted by the Frequency Clock. In this case, the software takes
a codec agnostic approach. Given that many people (including myself) have
archives online encoded with proprietry codecs the next best thing to
eliminating the archive and starting again is to make the codec
'invisible'. Eliminating the interface (the proprietary media player eg.
RealPlayer, WindowsMedia player) of the respective codec providers
is a small act of protest and a pragmatic approach to making the most of
living with some 'necessary' evils. Until the open codecs are well
supported (download yours today!) then ironically media encoded in free
codecs has a very limited audience. The argument is therefore, that if we
make the codecs invisible by removing the player interface and
representing all content within a unified media player (in this case the
Frequency Clock) we can help mediate a transition to content encoded in
free codecs. Half the battle for free media on the internet is for the
codecs, the other half is for the players.

When you (the content producer) has control over the player interface
then you can (for example) assist the user to download new codecs
seamlessly. This is the intention of the Frequency Clock player, to mix the worlds of free and
closed codecs so the transition from one to the other is easy. Its a lofty
aim and it won't be achieved alone by the software in this example but its
one small step and its better to take that step that stand forever on the
side of RealNetworks, Apple, and Microsoft.

By removing the player interface of these companies, you also remove the
advertising that is embeded in these interfaces. This advertising generates revenue
streams for Microsoft et al. Giving control of the interface to content
producers means these revenue streams are not built on the back of _your_
content.

> That users must open and close is only half true.
> Well, they must close it if it if the streaming is over, as they must turn
> off the radio when the day is over, but opening the player is done by the
> metafile (if the media is not embeded.) Maybe users do associate
> their new player with the different existing metafiles, as a replacement
> for the real, win, apple player (will this work, developments of new
> streaming media by the big companies will be faster than any subcultural
> approaches..and users will not want to miss it?)..another way would be to
> create a new metafile for the new player, is this a choise for
> producers?

As a small technical note, Heiko asks if new forms of meta-files can be
created for use by producers. As a summary to what I have said above, I
can say that this is only possible if producers have control over teh media
player, so this is not possible for the QuickTime, RealOne, and
WindowsMedia players but is possible for players (such as the Frequency
Clock player) which are open and you are free to develop and extend
yourself (or find a coder to do it for you ;-) ).

> IMHO what is needed is a simplification of streaming media, not more
> confusion. To see what is possible with what the industry does.
> And to see how frustrated users really are with the many players.
> IMHO content is more important, so I am keen to see how the content will
> be organised etcpp.
>
> mp3s are patented etcpp, this was and is no problem in reality.
> Why should it be different with mp4?

Many thanks to Heiko for raising these issues :-)

adam

Adam Hyde
r a d i o q u a l ia
free as in 'media'

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Date: Sat, 23 Nov 2002 13:10:06 +0100 (CET)
From: Heiko Recktenwald <uzs106@ibm.rhrz.uni-bonn.de>
Subject: Re: <nettime> streaming media software for arts released

> > > media player. If you watch a WindowsMedia file, it opens in the
> > > WindowsMedia player, a Real file opens within the Real Player and so on.
> > > Users must open and close a number of players in order to view different
> > > streaming media formats. This can be disruptive to the continuity of the
> > > experience.
> >
> > If you offer your content embeded in a webpage, you dont see much
> > differences in design anymore. Most content is presented today in this way
> > and you dont see anymore which plugin is acting.
> 
> Isnt this a good thing? I am not sure what your point is here, maybe it is

Yepp, it could look like many TVs in the room, all tuned to different
programs. I dont mind the minimal differences between different vendors
design. As long as it looks simple overall. There is no new software
necessary for that. Maybe we disagree here.

Lets imagine a multi vendor environement with mp4. I come from movies on
floppies. macs, pcs. So I am traditionaly, Berkeley etc, keen on MPEG.
(The DRM stuff in MPEG 4, should we care, or is this just another case of
gif?)
 
The problem would be how to do multivendor embeding. To have an embed tag,
however it is wrapped today into internet explorer pages, that is open,
not just the quicktime plugin with special quicktime tags

> important to you to see the codec of the content but I am not sure why. In
> terms of developing content this might be useful (the codec used can
> always be known by looking at the source of the html) but I am pretty sure
> most users don't care what codec content is made in until they discover
> they dont have the right codecs installed.
> 
> However the point of this software system - the Frequency Clock - (A point
> you touch on below) is
> that we should be very much aware that most audio and video content on the
> web is encoded by proprietary codecs. WindowsMedia, Real, QuickTime all
> use proprietary codecs including MP3. This means that almost all content

Yepp. But see the gif case.

> encoded for artistic, cultural or independent media purposes is encrypted.

Well:

> Encrypted in the sense that the content has been converted to a closed file format which can only be 'decrypted' by media players
> that have the requisite licenced algorithms. Hence the owners of these
> algorithms (Thompson and Fraunhofer, Microsoft, Real Networks etc) own the
> key, its not a public key, its a closed proprietry key. You, the content

In theory. 

> producer, cannot unlock this encrypted file unless you do
> so with the appropriate media player software usually  created by the
> software house that owns the codec.

Sounds maybe unnecessaryly mystic.

I really see the difference. Ogg is the case. Yepp, lets support it in
mp4s. Inside of mp4s, there are many problenms that are IMHO more
important than gifs and ogg. For example mp3s in mp4s. We have to
reencode content, if we want to add a timeline to existing mp3s. This
trashes a welth of music.

Those are the "keys" that matter. Apple and Cisco, Ciscos mp4s are
possible with mp3s and ogg. See Oliver Frommel mail on mp4s here.
(Well, there is also an Oliver Fromme.)

> This may seem ok now. As Heiko says later
> "mp3s are patented etcpp, this was and is no problem in reality.". However
> is it enough to trust that all will always be ok. Not discounting that

I dont trust, I know I am much more powerfull than any company, in the
sense of the gif case.

> closed codecs might cause problems in the very near future, just consider
> if you have encoded (encrypted) some video content with a closed codec
> (lets tajke RealNetworks audio and video codecs for this example).

This is a one way and so shitty anyway. But this junk is used in the most
popular and expensive modem live streaming environement.
mencoder seems to read some old codecs now.


> For now you might have the key (algorithm) to 'unlock' the content and
> replay it in a media player (in this case the RealPlayer). However we 
> can easily imagine a situation in X years time where Real has crashed 
> and burned and are no longer a technology provider. Where is your 
> content now? Your content

Yes ;-)

Dont use Real on floppies. (When you think the movie is the file, mpeg
movies are more beautifull.)

> could well be in a encrypted file format with no licenced keys to open it.

Well, I just want to repeat: Not all theoretical problems are problems in
reality.

Very best, thanks for the discussion, maybe we can discuss about content
and organisation of content too.

There is one problem, DRM in MPEG 4. But as with REAL real encryption,
we dont have to use it. I learned from Thomax to open http for rtsp in
Real. You could make the apache document root in /usr/local/movies.
The industry has no key to close this down.

H.

> The codec may have gone down with the company and you may be left begging
> users to download the older players that you have found in some arcane
> archive somewhere on the net, and who is to say the legal remains of (in
> this case) RealNetworks won't stop you from doing even that?. Distributing

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net