[osflash] tinkering with videoconferencing

[John Grden]

v0.5rc1 is what you need to check out.  They've refactored the streaming
code and put in bandwidth control and the initial tests I saw were
incredible.

So, get the latest trunk or download and install rc1 and try it all again.

http://www.osflash.org/red5/05rc1

On 7/11/06, network congestion <networkcongestion at gmail.com> wrote:
>
> Hi everybody,
>
> 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
> networkcongestion at gmail.com
>
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
>


-- 
John Grden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/osflash_osflash.org/attachments/20060711/7a546e1e/attachment.htm