| Bill Sanders 2005-04-19, 7:45 am |
| Hi Simon,
You're right in your Camera.setQuality() assumptions -- and I think=20
it's 20 minutes instead of 15 is the time it takes for the server to=20
come back to life--usually simpler just to reload it using the App=20
Inspector. Typically, when you exceed your BW, it'll lock up at some=20
point unless your usage is below your settings. So even if your=20
settings are at 210kb, it may not actually use that much. That setting=20=
specifies the max amount of BW your camera can use; not the amount it=20
must use. Thus, with 420kb total in your camera settings, if the users=20=
aren't moving much and only one speaker is talking at a time, you can=20
probably get away with your settings for a while. However, after they=20
kick in simultaneously, the server figures out that the bw is over the=20=
limit and quits.
Also, your microphone settings are not factored in either in the=20
Camer.setQuality() method. So, instead of only 210k per camera, you're=20=
using 210k + audio as well as any shared objects and calls to the=20
server that may add up.
By taking several samples of bw, you can work out what settings will=20
prevent your app from locking up -- usually a stress test where both=20
sides are talking and moving simultaneously should do the trick.
If you haven't seen it yet, Brian's chapters on Camera/Mic settings and=20=
BW/Latency provide lots of good tips on how to get things working the=20
way you want.
HTH,
Bill
On Apr 19, 2005, at 1:47 AM, Simon Skr=F8dal wrote:
> ...I think I have answered my own question... and I think I was right=20=
> in my
> initial assumption.
>
> The broadcast bandwidth usage does count, but on first run the FCS=20
> seem to
> allow the bw limit to be breached.
>
> However, upon disconnecting either application (broadcast/receiver)=20
> and then
> reconnecting, FCS refuses to play; "Current server bandwidth usage=20
> exceeds
> license limit set. Rejecting connection.".
>
> How long is the delay, before FCS allows connections again? I seem to
> remember it being 15 minutes?
>
> BTW, the bandwidth findings are my assumptions - if you have anything=20=
> to
> add/correct, please let me know.
>
> Thanks,
> Simon Skr=F8dal
>
> ----- Original Message -----
> From: "Simon Skr=F8dal" <simon-fOXyMSD3e6XvnOemgxGiVw@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Tuesday, April 19, 2005 3:05 PM
> Subject: Re: [FlashComm] Camera bandwidth
>
>
makes[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> one
> This
[vbcol=seagreen]
> the
[vbcol=seagreen]
> counts
[vbcol=seagreen]
> outgoing
> video
keep[vbcol=seagreen]
> the
[vbcol=seagreen]
flash[vbcol=seagreen]
[vbcol=seagreen]
> very
[vbcol=seagreen]
[vbcol=seagreen]
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|