Cause merry mayhem by voting for rtmpdump as "Best Multimedia"

Nominating rtmpdump for "Best Multimedia" project had the desired effect
of getting it up as a finalist.  Vote here for rtmpdump:

Why I, Adobe, Should Stop Peddling DRM
DRM does not work and you, Adobe, were foolish enough to drink the
cool-aid.  DRM does not work for many reasons:

From every perspective, DRM is a failure.  From a simple mathematical
perspective, DRM is a failure.  From a psychological perspective,
DRM is a failure.  From a technical perspective, DRM is a failure.
From a financial perspective for the users, DRM is a failure.  In a
competitive market, DRM is a failure.

The solution: you just have to go with the flow, accept the reality
and work with people's desires and abilities and financial
budget, providing them with the easiest and affordable
technical solution to get them their content and the multimedia
interaction that they desire.  By being the easiest to work with
(which other than your support of DRM, Adobe, it does have to be
said that your products are by far and above the easiest way to
present multimedia) you automatically gain market share.

The sooner you, Adobe, and your customers, accept this reality, the
quicker that everyone can get down to the business of developing
exciting technology (such as RTMFP) that is actually useful
to people.


RTMP is an important network protocol which is utilised to communicate
audio and video.  Adobe, you have no right to restrict internet communication
or to tell people how they can and cannot communicate, or in what format,
and can go fuck yourselves if you think that you can bully people into
submitting via a blunt instrument called the "Digital Millenium Copyright Act",
a law which should never have been allowed to have been bought into
U.S. law in the first place.


RTMPE is an extension to RTMP to include encryption of content.
A clean-room specification is available here.
Please distribute freely and widely.  Please implement and distribute
free software source code implementations even wider.

Note to Adobe: fuck you and your attempts to call the use of industry
standard crypto primitives "proprietary".

Download rtmpdump 1.9 Source code

Source code of rtmpdump v1.9 is available here.
A lovely November 2009 "Friday 13th" release.

Download rtmpdump 1.6 Source code

Source code of rtmpdump v1.6, with the get_iplayer application removed
(because i don't like the idea of providing people with the means to rip
off copyright content), is available here.

There is also a bittorrent tracker running: here's the rtmpdump v1.6 torrent

Unpacked source (for the adventurous)

Why would I remove get_iplayer yet still provide the source to rtmpdump?

get_iplayer is utilised to make copies of copyright material.
encouraging people to do that is stupid.

by contrast: rtmpdump is one of the VERY few free software
implementations of a really important networking protocol,
implementations of which I have been hunting down and looking for,
for a considerable amount of time.

my interest in RTMP is to encourage the creation of free software
real-time audio/video communication software, and, as you can see
from e.g. Red5, there do exist implementations,
just very few of them.

Throwing out the baby with the bathwater, by going after free
software developers with a DMCA take-down notice, is just stupid.

Translation: "Adobe - get fucked".

Proprietary Implementations

For fits and giggles, here are a few fun items involving proprietary

Translation (sing along if you like): "Adobe come and geeet uuus, Adobe ..."

Is the RTMP protocol documented anywhere?

Yes.  Just not by Adobe.

Here is a list of web sites that document the RTMP protocol:

Translation: "Adobe - go fuck your proprietary implementation"

Is this server in the United State?

It's in Maidenhead, UK.  So, no.  It isn't.  Translation: "Adobe - fuck off".

Analysis of RTMPE

RTMPE is definitely not a "Copyright Protection" mechanism.

An analysis of RTMPE (see "Analysis" section)
shows that RTMPE does nothing more than what SSL already does
(provide end-to-end secrecy, except without the protection against
man-in-the-middle attacks - RSALabs on DH, para 5)
and simply mathematically links a publicly-downloadable and
publicly-obtainable SWF file to the connection.

Bottom line: All the information required to obtain the content is
publicly available.  There is no "security".

If the information isn't publicly available (such as the SWF file to
be executed in the web browser) then the content cannot be obtained,

Unfortunately, this leaves Adobe in the shit, if they've been
claiming that SWF verification is somehow "secure".  Anyone reading
this who has bought into Adobe Technology on the basis of "security"
or "protection" is advised to initiate legal action against Adobe,
seeking compensation and damages for deceiving them about the level
of "protection" of their Copyright material.

From Adobe's Web Site:
'(swf verification) ensures that only your SWF or AIR files can connect to your application or content on Flash Media Server'.
This is false. The correct interpretation is:
"if anyone can obtain the publicly-available SWF or AIR file (or a hash of it, and knows the SWF or AIR file's size) they can also connect to your application or content".
Translation: "Adobe, you fucked yourselves, royally, without anyone's help." Are there any 'encryption' keys in RTMPE? No, there are no encryption keys in RTMPE. There are however three magic constants which are used as input. And, remember, also, the publicly accessible SWF file - the one which you put on the web site to view the content - is used as input to the algorithm as well (or, at least, its hash and its size). So if you want to get genuinely stupid, and consider the sentence "Genuine Adobe Flash Player 001" to be a quotes key quotes, then by that definition, so is the publicly accessible SWF file also a quotes encryption key quotes. This raises some hilarious implications: This latter is quite easily achieved. you just block *.swf files. Actually, all Free Software HTTP Proxy and Web Browser projects should not risk being subjected to DMCA takedown notices and should block all swf files, just to be on the safe side. ... after all, it's not like they can analyse the content being streamed by the SWF file, because that would require either reverse-engineering the SWF file on-the-fly in order to find out if it uses RTMPE, or setting up a complex system of analysing network traffic (again, which would be, like, illegal, like, cos you'd have to, like actually identify RTMPE and would need to, y'know, know the algorithm?). Presumably, though, on detection of RTMPE, then, well, by that time, it's too late: the browser will have already received and be executing the SWF file. So, presumably, right, like that joke computing language which had a "GO FROM" statement and an "IF THEN ELSE UNLESS" construct, you'd have to somehow undo the past, and, presumably, if that wasn't possible, try to hide the fact that you were unable to predict the future, by deleting incriminating evidence from the user's machine and then crashing it. Who else is hosting the RTMPE source code? Anyone else who would like to be added to this list, contact me via the methods shown on my main page. You will be expected to indicate that you do not encourage copyright infringement. Bittorrent sites hosting torrents for the rtmpdump v1.6 source code. These have sprung up instantly, the moment that the slashdot article appeared online. Ain't ya just gotta love that "fuck you, Adobe" attitude... Authoritative Opinions on Adobe's actions Even my seven-week-old daughter is able to give her valuable and authoritative opinion of Adobe's decision to use the DMCA to restrict Software Freedom: