Dominick Accattato, CTO Infrared5

Here’s an interesting video on the evolution of security!

If you’re just getting into Red5, and you are wondering what it’s capabilities are and how you could approach saving audio/video streams with Red5, then please read on.

Recently on the mailing list, a question on how to save streams to the server came up via a new Red5 user. The user was kind enough to explain that they hadn’t much knowledge on the subject and that they did their due diligence by searching the web for answers.  Unfortunately, there is a lot of information on saving streams, but most of it is geared towards long winded examples and less on teaching the user what they need to do to get from A to B.  Keeping this in mind, I gave the following answer which instead of providing an entire example, just gave him the tools and knowledge to get to their next step in the red5 evolutionary process.  Soon, this user may be spreading the knowledge back by providing these same answers to other users or contributing to our wiki.  My suggestion is as follows:

I would suggest that you take the following approach:

• download and install red5
• open up the home page screen (http://localhost:5080/)
• install some examples
• look for an example that does something you’re looking for.. probably oflaDemo in your case or the publisher application.

once you have this 50,000 foot view, you will can check out the example code and look at what API you will need.

In your case, you’re going to want to look into the following Clientside API:

• NetConnection
• NetStream

example:

// create the connection
var nc:NetConnection = new NetConnection();
nc.connect("rtmp://localhost/myApp");

// create the stream
var ns:NetStream = new NetStream(nc);
ns. publish("myStreamName", "record");

The result will be an FLV file named “myStreamName.flv” located in your webapp’s streams directory.  This happens automagically on the server.  Of course there are ways to monitor and prevent this automagical functionality, but it’s a good start.

Also, keep in mind that the code above just publishes… there are equivalent api calls to play a stream: e.g.:

ns.play(”myStreamName”);

Hope this helps…

For those of you who have held back on working with Xuggle due to their restricting AGPL licence you can now breathe a sigh of relief and head on over to the xuggle site.  The Xuggle team has released a new version named “Eliza” and ain’t she pretty! In addition to the release, they have slapped the good old LGPL license back on the packaging.  What this means is that you can now use Xuggle 3.3 with your products without:

Instead, you can now freely use Xuggle 3.3 as you please.  The only restriction that LGPL places on your project is that you must contribute back any code modifications to the source code of Xuggle.  You should all be pretty familiar with this licensing model since it’s used with some of your most prized open source technologies such as Tomcat and your’s truly Red5! Many of you might remember that Xuggle 1.x was also licenced under LGPL, however starting with 2.x, the licence had been changed to AGPL. The news of LGPL is a big win for the Red5 community.  Good to hear and I thank the Xuggle team for their contribution.  So what are you waiting for, go get Xuggle 3.3 Eliza!

Head on over to Chris Allen’s site and get another inside look into the development of Trench Run on the iphone.

 As you learn more about Spring dependency injection and the benefits it brings to your application, you will undoubtedly run into namespace conflicts within the classloader mechanism.  Most likely, issues arise when you have dependencies in more than one location.  This is the case with many who have Spring JAR’s in their “myApp/WEB-INF/lib/” directory.  The reason is because Red5 is based on Spring and thus has these JAR’s in the common lib directory “RED5_HOME/lib”.  Below is one exception I receieved today and I was able to fix the issue by removing duplicate jars from under my web applications lib directory.  Many times, the error doesn’t seem obvious so always keep this in the back of your head.  I would imagine that each web application should not conflict with the top level classloader, but I have much more investigation until I can say for sure why this is happening.  That said, I have read about JAR conflictions among the Tomcat community as well.

java.lang.IllegalArgumentException: Class [org.springframework.ejb.config.JeeNamespaceHandler] does not implement the NamespaceHandler interface

If your getting this error, just make sure that you have the same Flex SDK on both the dependent SWC’s and the Flex Project.  In addition, after bringing in the SWC make sure you do a clean and build on the project.  Then the error will be gone.

origin lead came from http://theagiletdog.blogspot.com/2009/07/solving-error-2007-parameter-blendmode.html

So I recently issued a Mac OSX update.  Afterwards, I wasn’t able to run the Red5Plugin.  It kept telling me that there was no JAVA_HOME defined.  Something was being spit out like:

“/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/bin/java” (-1)

true enough that directory didn’t exist.  However, running Red5 from the terminal gave the intended result.   So I was confused as to why eclipse wasn’t using the same JAVA_HOME that I had set in my ~/.bashrc file.  It turns out that eclipse as well as other Java applications use ~/.MacOSX/environment.plist.  So if you have the same problem, just open that file, change the JAVA_HOME to point to the correct location.  For me, it’s /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home.  After making the change, log out and back in and eclipse and the Red5Plugin should work fine again.

For more information, check out this post: http://lindaocta.com/?p=38

Install Instructions here:

http://trac.red5.org/wiki/Red5Plugin

Configure Project instructions here via Jon Valliere:

http://trac.red5.org/wiki/Red5Plugin/CreatingRed5Projects