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
[EMAIL PROTECTED]
On 7/12/06, Luke Hubbard <[EMAIL PROTECTED]> 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.
- LukeOn 7/12/06, network congestion < [EMAIL PROTECTED]> 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
[EMAIL PROTECTED]---------- Forwarded message ----------
From: Luke Hubbard < [EMAIL PROTECTED]>
Date: Jul 12, 2006 12:39 AM
Subject: Re: [osflash] tinkering with videoconferencing
To: Open Source Flash Mailing List <[email protected] >
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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
>
>
> _______________________________________________
> osflash mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
>
>
>
> --
> John Grden
> _______________________________________________
> osflash mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
>
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
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
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
