gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] RMTPE specification


From: Rob Savoye
Subject: Re: [Gnash-dev] RMTPE specification
Date: Sat, 23 May 2009 14:30:25 -0600
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

Luke Kenneth Casson Leighton wrote:

>  ah that's fantastic - was tracking that and found it wasn't quite
> working, six months or so ago.  that's _really_ good news.

  6 months ago it wasn't. I got it working pretty well over the winter
and early Spring. A friend is already using it for streaming video on
his web site. It's progress has been slower than I like cause I also
have to work on Gnash as well, support myself, that kind of thing. I'd
love to have somebody pitch in and work on it with me so it'll stop
being a solo project. Most of the code in Cygnal is shared with Gnash.

>  well i'm interested in having something _other_ than red5, because i
> really don't like java.

  I dislike Java too, which is one of the reasons I wrote Cygnal.

>  will you be planning to call out to other dynamic languages at some
> point (e.g. python, ruby) ?

  The plan is to support multiple server side scripting languages like
python and PHP, in addition to ActionScript. This is the part I'm
working on now, as each scripting language runs as a separate process
that I communicate to using a socket.

>  if there's a way to do real-time video chat (like red5 can) in cygnal
> then that's a _major_ milestone.

 That's the plan, hopefully done by the end of summer. All the remoting
parts in both Gnash and Cygnal are working fine. Our twist will be that
we'll be using Celt, Speex, and Theora instead of NellyMoser and MPEG4
when talking to Gnash instead of Adobe.

>  btw i trust that you've found that implementing both the client and
> the server at the same time allows you to bootstrap up _much_ quicker
> than if you just did client or just did server.  you may also find

  Other than it taking twice as long, it *is* better to implement both
server and client side at the same time. :-)

> that implementing a sniffer (wireshark plugin?) at the same time also
> helps, although i'd found when doing MSRPC reverse-engineering that
> massively verbose debug output substitutes for that need, anyway.

  You can see my the video of my talk on reverse engineering RTMP at
FOSDEM this year, to see how I like to do this. Wireshark has RTMP
support these days. What I did was take a pile of hex dumps I'd
captured, and turned them all into a giant testsuite. That way I didn't
need to use the Adobe plugin, which I'm too paranoid to even get close to.

        - rob -




reply via email to

[Prev in Thread] Current Thread [Next in Thread]