In the last couple of days I’ve fixed several issues in Red5 to get it ready for 1.0. Luckily some of these fixes resulted directly from projects being worked on at Infrared5.
The first issue looked into was with shared object usage with RTMPT. This issue seemed to by caused by the way that we manipulate the classloader hierarchy. A word of warning: working with classloaders can be a very scary task and not one that any novice Java developer should want to take on. Briefly, each Red5 application has its own classloader which is separate from any other Red5 application; this is mainly for sandboxing and is the way in which all JEE application servers operate. The internal instances (if enabled) of RTMPT and RTMPS are started in the Tomcat loader thread after all of the applications have been initialized and thus they cannot access the Red5 applications individual classloaders; meaning they can’t share SO’s etc. For that reason I never recommend using the internal instances and instead suggest that implementers use the RTMPT servlet within their Red5 application; this is a simple addition to their web.xml. In the end, after working on this bug and an RTMPT binding issue at the same time I found that the classloader issue was fixed by making sure the internal instances were binding to an IP, instead of allowing Tomcat to handle it as it saw fit. It would appear that Tomcat has some sort of sharing in-place that allowing web application classloaders to talk with each other. The “fix” has been added to trunk around revision 4241 and will be in the 1.0 release configurations.
The last two things that I resolved today were found by using FMLE 3.2 as a test publisher. I must state that we as a team cannot support FMLE due to its EULA, but it is a very handy and capable application for streaming to your media server if you want something other than Sorenson and NellyMoser. I didn’t find any specific issues for “onFI” or AAC live streaming on the tracker, but these are the two items I fixed using FMLE. The initial work for AAC was done early-on by Tiago and modified by Vladimir Hmelyoff, so a big thank you to them. Fixing live streaming with h.264 and AAC was as easy as making the ClientBroadcastStream check for audio codec information and setting it if it was absent; I love ez fixes! To fix “onFI” I had to dig around on Google to find out what this call was, for those who don’t know it is used for active timecoding in a stream. The publisher will send the local system time and date as strings in a mixed-array, keyed as “st” and “sd” respectively. All that needed to be done by Red5 at this time was to handle the callback and pass it on to the subscribers.
One last note about FLME, when you stream live it will send parameters with your stream name and we used to simply ignore them. These parameters are now stored on your broadcast stream and may be accessed on the server side by calling getParameters().
Lastly, I don’t know when 1.0 will be available but you may all certainly use the current RC2 version in SVN.