The idea of the small embedded red5 is outstanding. The sooner that this can be kept current with the trunk, the better. I like the approach of it being built into the source tree of Red5 with special build script so it can be built from the trunk at any time. This is even better and more flexible than the .war distro IMHO. This would allow us to fully integrate Red5 into our applications and streamline deployment.
An interface for VoIP integration would be great. If it was possible to establish a SIP client with two way RTP audio with the Red5 server, then we could set up a voice conference on our PBX and have Red5 'join in'. We use an Asterisk VoIP PBX. We use OpenAMF for all application integration, so if AMF is 'pluggable' that would be good. Even the ability to choose which AMF you wish to use might be an idea to consider. I don't know if that's practical, or even if the AMF support in Red5 is superior to OpenAMF. At the moment, our application servers are separate from our media servers. The ability to store and use digital assets outside of the Red5 application/container is something we would like. For example, if we allow our customers to upload flv or other assets to the server, then we'd like to keep each customers upload folders separate from each other. The homes folder seems logical and easy to implement from a user controls standpoint. Also, if an application is set to stream and record a publishing point, then the resulting flv file should be stored outside the application, so that a re-deployment of the application doesn't wipe out the stored flv's. I think this approach would also allow us to build a digital asset management system that could work in conjunction with Red5. Scalability and stability are important. Probably number one on our wish list is stability and robustness, particularly on the live streaming side. Our most common use of the server is for live publishing and streaming of video events. The events are streamed live and recorded. Our audience can range from a few dozen to a few hundred at any given time. Total viewship can reach into the 1000's over the length of the live event. Our typical video quality is 320x240 at about 300-500kbps per stream. We only see this demand growing. Soon, our live concurrent viewers will reach over 1000. To support that, we will need to load-share the stream. I'm guessing some kind of clustering of multiple red5 servers (with DNS round robin load balancing?) would be in order. I'm not a server/network engineer, so I don't know how this would work exactly. That's all I can think of at the moment ;-) Bill Steven Gong wrote: > Hi all, > As was discussed in the thread "red5-minimal, small embeddable red5", > I'd like to post this thread here to collect different usage models of > Red5. If you used Red5, are using Red5, would like to use Red5 or just > insterested in Red5, please reply to this post to describe what usage > scenario you are facing and what feature set you want from Red5. You > could also describe how you are using Red5 right now and what > improvement you need from Red5. > > I will make a summary after enough opinions have been collected. > Thanks a lot. :-) > > -- > I cannot tell why this heart languishes in silence. It is for small > needs it never asks, or knows or remembers. -- Tagore > > Best Regards > Steven Gong > ------------------------------------------------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
