Yes I know it's not supposed to be production-level code etc. However it was so easy to get red5 running and then I got sucked into reading the sample code you guys provided and have been playing with it ever since. Eventually this thing has to go into production, so hopefully somebody will find this of interest. Even though on a technical level my interventions are not much more sophisticated than those of a monkey banging a hammer on a space shuttle.
I started with 0.4 and basically took the sample FLA and made one window really big (subscriber_o). I've been checking out the trunk build daily with svn. I've been playing with the settings in Broadcast.as (and have added a few of my own), but basically what I am shooting for is this:
sound at either 22 or 44Khz
320 x 240
10-12 fps
80-95% quality
mic gain of ~30
sometimes I try to limit the video bandwidth with setQuality (eg mic.setQuality(30000,90))
etc etc
I am running the Sun JDK 1.5.006 on Centos 4.3
I have two servers running:
a dual Xeon 2.8 on in-house wiring (cat6, 100Mbps etc)
this server can connect internal to internal, internal to external (DSL)
a celeron 2.4 tier1 dedicated (10Mbps) in a real data center. A real server.
First of all, there is a dramatic improvement in the quality of the sound. Put another way, using red5 0.4 code to carre 44Khz of voice worked pretty well, but every 10 seconds there was "...CLICK.fpoosh...normal sound again" That is now, thankfully, gone.
Re video: the video carriage seems the same as before, although perhaps not as chunky (there was a wee bit of chunkiness before, less so now). In terms of delay, depending on the length of the connection the delay between the sound and the real world starts at around 0.4 seconds, but can increase to up to 10 seconds. I was able to walk from one room to another and see myself leaving the previous room. But then again, the delay sometimes corrects itself.
I have also noticed a bit of de-synchronization between audio and video, the police academy talking delay effect. I could be imagining this but I would say that the audio and video were less synchronized today using trunk code than they were using 0.4 code on Friday of last week.
All in all, something must have improved because the audio transport is more stable and does not cut out 1 second on 10 as it did before. I've flagged the synchronization and delay issues not as complaints but as feedback.
Hopefully as my understanding improves (especially as I now look at server-side code) I will be able to bring actual, you know, information to the table. But such as it is, I hope you enjoyed this humble report from the field.
Network Congestion
[EMAIL PROTECTED]
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
