[Red5] Fwd: [osflash] tinkering with videoconferencing

Wed Jul 12 15:05:38 EDT 2006

Thanks for the great reply.

I have a clearer idea of the factors involved. In the meantime, if I
understood correctly, if I try to send an encoded signal that is less than
500Kbps, should that make a difference in terms of delay ie will there be
less of an accumulation of extrra frames or whatever?

Also for my own education is that 500K limit set server-side or client-side?
I've look through the source for the ofla_demo and videoconference but so
far it has eluded me.

Network Congestion
networkcongestion at gmail.com

On 7/12/06, Luke Hubbard <luke at codegent.com> wrote:
>
> Hi,
>
> Yes. This is because we now have speed control on the streams. Let me give
> a quick background..
>
> Pre 0.5 we streamed as fast as we could push those packets down the pipe.
> Once each packet was written the next was pumped out. The upside of this was
> that the client buffer filled really fast (almost instantly on a local
> network), and video plays straight away. The bad part of this is we have
> streamed the whole file to the client in a couple of seconds on a local
> network, or faster than we need to on the Internet. Quite where the packets
> queue up we didn't really figure out, its on the client side, could be os
> networking layer, could be in flash player memory. It worked, but I wouldn't
> want to through a big 100mb plus file at it.
>
> In 0.5 we have a system to control the rate of streaming. This is all
> quite flexible allowing rates to be set on server, applications,
> connections, streams, etc. There is a background thread that hands out
> tokens and the streams consume them. In ofla demo its set to something
> 512kbps. This works, you can see the pulp clips are slightly higher bitrate,
> so the speed of streaming is almost the same as playing but a little less so
> it pauses ever now and then. For the star wars clip to streams ok, as the
> stream bitrate is higher than that of the clip + protocol.
>
> So whats up? Well our flow control code is new, and we are learning how to
> best use it. Ideally for VOD we want to stream like in 0.4 until we fill
> the client buffer then reduce the speed down to be equal to that of the data
> bitrate. Adjusting as we go, since streams may have variable bit rate,
> ensuring the client doesnt need to pause. This should give the best
> experience for the user dont have to wait long for it to start, then have a
> nice steady stream, plus we dont want to waste server bandwidth handing out
> bytes the client may not watch. We are working on adding the code to do this
> before 0.5 is out. It will be configurable, so you may stream ala 0.4 if
> you want, or come up with your own algorithm for optimum stream bitrate
> graph.
>
> I hope that didnt sound like a ton of techno jargon.
> If it did, just take away the knowlege its on our list of priorities.
>
> - Luke
>
> On 7/12/06, network congestion <networkcongestion at gmail.com> wrote:
>
> > (originally on osflash)
>
> Hi,
>
> Regarding the difference between 0.5rc1 and 0.4:
>
> I did the tests this morning side-by-side on an unrealistically good
> network setup (house wiring 192.168 etc). Unfortunately, it would seem
> that for a videoconference the delay on 0.5rc1 is approximately 10 seconds
> whereas on 0.4 it is approximately 0.5 seconds, and the pattern seems to
> hold over time.
>
>
> Network Congestion
> networkcongestion at gmail.com
>
> ---------- Forwarded message ----------
> From: Luke Hubbard < luke at codegent.com>
> Date: Jul 12, 2006 12:39 AM
> Subject: Re: [osflash] tinkering with videoconferencing
> To: Open Source Flash Mailing List <osflash at osflash.org >
>
> Hi John,
>
> I think he is testing RC1, well trunk and RC1 are close at the moment.
> I can answer a few of the questions / observations.
>
> 1. Audio and video out of sync. We recently added packet dropping to
> video and switched to relative ts. Obviously we haven't got it quite
> right yet. I think we need to not only drop the packet but add the
> relative ts the next packet to be sent. This way all the timers should
> stay in sync. Will look at sorting this before 0.5.
>
> 2. The flow control in streaming still needs to be more dynamic. At
> the moment we have a set speed.. say 500kbps. So it takes a while to
> fill the buffer at the start. The code will adjust speed according to
> client buffer and server side buffer. This should allow us to fill up
> the buffer as fast as we can, then switch to a more steady rate which
> adapts based on bit rate. Again this is something we are looking at
> sorting be for 0.5 proper.
>
> The feedback is exactly what we need, although perhaps better
> submitted to the red5 or red5devs list.
>
> Thanks for your email.
>
> - Luke
>
> On 7/12/06, John Grden <neoriley at gmail.com> wrote:
> > 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
> > _______________________________________________
> > osflash mailing list
> > osflash at osflash.org
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> >
> >
> >
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20060712/189b6480/attachment-0001.htm