Sunday, February 13, 2011

Finally Red5 1.0 RC1 is Out - Give it a try

Lately I was not following Red5 but recently I got to know about the release of Red5 1.0 RC1. It's a much awaited release of Red5. Now you have a pretty stable media server in place so you can build interesting applications using it. You can download the latest 1.0 RC1 version of Red5 from the following download links-

Red5 1.0 RC1 (Release Date : 2 February 2011)

Windows | ZIP | Tarball | OSX | WAR

3 comments:

droid said...

red 5 1.0 rc links not working!!
"Resource/Page/Link not found" issue...
What's going on? did red5 team pull the 1.0 files?

Mágico Cajones said...

Does red5 support actionscript3?

damackster said...

Dudes

Suffering from Red5 blues :o(

I designed an app that I've wasted cash on offshore developers (I have extremely limited funds)that has a component that delivers a web conferencing e-learning facility. It offers live and pre-recorded A/V delivery with screen capture/record. The application 'works' except the quality of the streamed screen capture is 'poor' to put it kindly (think Atari circa 1983). The issue it seems is when dealing with H.264 codecs. Its either High quality with too high bandwidth or its Useless quality with minimal bandwidth.

Facts:
* We are working on replacement of ScreenCodec2 with H.264
* We are using Red5 (yes, not the greatest of choices but cost is an issue for now)
* As you know, in java there is no proper implementation of H.264
* The x264 library is the best optimised library for H.264 , but its coded in c and c++
* Unfortunately we don't have this library in java
* ffmpeg is also an open source tool which we need installed on the machine
* This tool can convert the rtmp stream on the fly from one type to another
* We also used xuggler java api to encode our stream, but this api is not working properly and the quality is not much improved
* Weirdly, using xuggler we got fantastic quality but found a painful 30-40 seconds delay when it starts to send packets
* We have the sourcecode for xuggler
* We debugged the code and found that ffmpeg presets are creating this delay
* As you know, there are many presets for H.264 such as normal, default, HD etc
* When we set the codec type to H.264 in xuggler, we need to load a ffmpeg preset file
* Using this file xuggler encodes the bufferedimage into iPacket
* Using xuggler we can write the video in FLV container only however, Xuggler doesn't write the video in F4V container, which is the mp4 container
* Unfortunately, also Red5 don't support the F4v container
* Using Xuggler H.264, we can write the video in FLV format thus its xuggler's limitation
* We tried to write the video in F4V container using xuggler but it won't play that video

All sense tells me that the issue is highly likely to be a configuration issue within the settings as opposed to something coding-related. Probably a blindingly obvious little thing but its causing me a serious pain in the rear.

Any pearls of wisdom, dudes??

Should I be looking at another H.264 Java API, other than xuggler, which is compatible with Red5??
Perhaps the developers are lost in detail and not looking at this methodically. I feel like I'm banging my head against a wall.

Dean: damack1@hotmail.com

Technology makes life easier

Daily Technology Tips

Open Source Flash Jobs

Adobe Flex Developer Center: Recent tutorials

Programming Discussion Forum