Swfdec - Jul 2008 - client command-line or library for streaming audio and video - does it exist?

folks, hi,
this message goes out to all the relevant mailing lists.
for streaming audio and video, critical to performing inter-red5-server
transfers,
and integration into other free software projects, and critical to the
development of gnash and swf-dec is the existence of a command-line client
and/or library for uploading (and downloading) AMF-formatted streams to and
from a flash media server such as red5.
does such a client - or library - exist, that anyone knows of, in any language -
c, java or python?
for example it should be really trivial to write a plugin for kopete or
gaim / pidgin to utilise red5 (or rtmpy when it's ready) as a audio-video
media server.  this would be a first big step to adding webcam support
to gnash and swf-dec.
the reason why i am asking is because i would like to see some integration
of real-time audio broadcasting into some of the "music production"
software
for linux.  so, whilst someone is doing a live performance (dj or broadcaster)
their production is going out real-time onto a red5 or rtmpy server.
l.

On Mon, Jul 21, 2008 at 9:13 PM, Rob Savoye <rob at welcomehome.org>
wrote:
> Luke Kenneth Casson Leighton wrote:
>>
>> development of gnash and swf-dec is the existence of a command-line
client
>> and/or library for uploading (and downloading) AMF-formatted streams to
>> and
>> from a flash media server such as red5.
>> does such a client - or library - exist, that anyone knows of, in any
>> language -
>> c, java or python?
>
>  Gnash has utility/rtmpget, which is a command line utility for
> downloading/uploading of video files via RTMP. It's written in C++, and
uses
> other Gnash internal libraries for most of the heavy lifting. Right now to
> use RTMP anything, use the 'rtmp' branch of Gnash instead of trunk.
 ok - right - well since this message, rtmpdump has come out!

 version 1.6 is available here:  http://lkcl.net/rtmp

 l.

On Sat, May 23, 2009 at 7:42 PM, Rob Savoye <rob at welcomehome.org>
wrote:
> Luke Kenneth Casson Leighton wrote:
>
>>  ok - right - well since this message, rtmpdump has come out!
>
>  rtmpdump this week got a DMCA takedown request at Sourceforge as well
> from Adobe, which for now means we also can't distribute
'rtmpget'
> either.
 it's the RTMPE encryption that they're after.

 perhaps eben moglen might be able to assist. moglen at softwarefreedom.org

 l.

On Sun, May 24, 2009 at 1:22 AM, Eben Moglen <moglen at
softwarefreedom.org> wrote:
> On Saturday, 23 May 2009, Luke Kenneth Casson Leighton wrote:
>
>   it's the RTMPE encryption that they're after.
>
>   perhaps eben moglen might be able to assist. moglen at
softwarefreedom.org
>
> Thank you for the suggestion, Luke.  The Software Freedom Law Center
> provides free legal assistance to non-profit makers and distributors
> of FOSS.  If any current SFLC client, or any individual developer or
> non-profit community member receives a DMCA takedown notice or other
> legal communication from Adobe or others concerning this matter, we'd
> be happy to help.  Write help at softwarefreedom.org and mention this
> correspondence, or write me directly if you prefer.  In the meantime,
> though we should be alert, let's avoid jumping to conclusions.
>
> --
>  Eben Moglen                            v: 212-461-1901
>  Professor of Law, Columbia Law School  f: 212-580-0898       moglen@
>  Founding Director, Software Freedom Law Center            columbia.edu
>  1995 Broadway (68th Street), fl #17, NYC 10023        softwarefreedom.org
 eben, thank you.  i've alerted the author of rtmpdump, as, according to
this:

http://linuxcentre.net/rtmpdump-can-be-used-to-download-copyrighted-works-like-a-web-browser/
http://www.chillingeffects.org/anticircumvention/notice.cgi?NoticeID=25159

it looks like sourceforge caved in and gave adobe his contact details.

a quick analysis of the algorithm show it to be nothing more advanced
than what SSL does.  there is no input from passwords.  the
verification process takes the size and a hash of the SWF file (which
is being executed in the browser) as inputs, and mashes it with
information that is pubicly exchanged.

there is no security.

there is only end-to-end secrecy (just like SSL).

anyone who know the algorithm and can download the swf file can
therefore obtain the content.  given that swf files are published on
web sites this all seems pretty dumb.

it's certainly not a "protection" mechanism.  it's more of a
"verification" procedure.  "have you now or at any time
downloaded the
swf file? was that a mathematically-irrefutable yes?  okaay you can
have the content then".

make of that what you will, but i'd say that it's definitely not a
copyright protection mechanism.  all the information needed to obtain
the content is publicly available.

l.