Various ramblings-on, mostly about Red5

12 Jul 11 Red5 fixes galore

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.

Reader's Comments

  1. |

    Nice work Paul and the team! Can’t wait to see what 1.0 brings :)

  2. |

    […] Visit link: Red5 fixes galore […]

  3. |

    Hi Paul

    First up thanks for all the work you and the Red5 team have done. Red5 has made so many things possible I could not have done otherwise. I use it in schools for audio/video and interactive activities.

    I have a need now to implement RTMPT so that schools can access my Red5 server when behind firewalls and http proxies. Some of the activities will be shared objects, so this post is quite relevant.

    I read a previous post of yours explaining how to set up Red5 HTTP and RTMPT to listen on port 80. This seems to be quite uncharted territory.

    Anyway, my question is whether it sufficient to enable RTMPT for my web app by:
    i) uncommenting the RTMPT bean in red5-core
    ii) adding the servlet declaration in my web.xml

    For my app, Tomcat serves nothing up via HTTP(Apache does that). We simply plan to port forward incoming traffic on 443 to the default RTMPT port 8088. Do I still need to define a default servlet mapping, or should the steps i) and ii) be sufficient?

  4. |

    Hi Paul

    Actually I got it working. I just left the http and rtmpt ports as the defaults(5080 and 8088) and used the servlet declaration and mappings from your post: rtmpt and red5

    Then I just forwarded port 443 to 5080, and now Red5 is accessible from behind proxy servers and firewalls via port 443.


Leave a Comment

Fatal error: Call to undefined function akismet_counter() in C:\xampp\htdocs\paulgregoireblog\wp-content\themes\googlechrome\footer.php on line 9