Min Bitrate & Max Bitrate

In my tests of the new webcast system (portal.ldswebcast.org) I've noticed that by default the system is setting the receiving feed at a very low bitrate (100KBps). This is even the case when doing a test receive webcast. If I manually set the min bitrate to 500 KBps however it jumps up the higher quality and has no issues at all receiving at that rate. Do most of you let the system decide your minimum bitrate or raise it up because of this issue? Also we noticed in our full test broadcast today that some sites have 1024 KBps connections but some one site had a max of 500. This was a building that had above average bandwidth. Why would this be? What determines the max bitrate?

And lastly, what is the stabilizer setting on the receiving streaming site (Defaulted to 1) and what do the red line and green light represent in the graph on the left?

mikevandre wrote:What determines the max bitrate?

I'd expect the bit rates to be set by a quick "speed test" to the server. If the system is loaded with other traffic or otherwise temporarily slowed, the system is going to see less is available.

Keep in mind that for streaming, it's the sustained bitrate that's important. Not the advertised or claimed rate. It's entirely possible for a "higher" building to actually have a lower usable bitrate.

mikevandre wrote:I've noticed that by default the system is setting the receiving feed at a very low bitrate (100KBps). . . . however it jumps up the higher quality and has no issues at all receiving at that rate. Do most of you let the system decide your minimum bitrate or raise it up because of this issue?

We tested and then used the system for the first time this week. We just let it fly on its own.

mikevandre wrote:Also we noticed in our full test broadcast today that some sites have 1024 KBps connections but some one site had a max of 500. This was a building that had above average bandwidth. Why would this be? What determines the max bitrate?

The system gets feedback from the receiving site and knows how well the feed is streaming. It adjusts in real time to the actual bandwidth getting through to the receiving location. As russellhltn said, what is real and what is promised are two different things (not only in life, but in the Internet world, as well).

mikevandre wrote:. . . and what do the red line and green light represent in the graph on the left?

On the display I saw earlier this week (first time test), they show what speed the connection is running at the moment. You can watch it step up to 1M as the feed works well and drop down when there are problems.

russellhltn wrote:

mikevandre wrote:Keep in mind that for streaming, it's the sustained bitrate that's important. Not the advertised or claimed rate. It's entirely possible for a "higher" building to actually have a lower usable bitrate.

If it is pushing out a lower bitrate wouldnt that mean that I'm not able to support the higher bit-rate at the moment? That doesnt appear to be the case because if we force it to the higher bitrate (by pushing up minimum) then it has no troubles.

mikevandre wrote:That doesnt appear to be the case because if we force it to the higher bitrate (by pushing up minimum) then it has no troubles.

Maybe. But it may sense that you're pushing the limit and it has no headroom to make up for small glitches.

Our experience in testing, and during Stake Conference today, is that the software is severely conservative. It seems to error on the side of avoiding the slightest amount of buffering. Most of our receiving connections stayed at 100K. We manually changed some because we are willing to buffer once or twice to have 300K or 500K. 100K is barely worth watching.

Another disappointment is that 500K seems to be the max bitrate for receivers. We have never been given the option to receive at a higher bitrate. Is that a system limitation? Is there something special we need to do to receive at a higher rate?

I have done several webcasts using the new portal, in March we were not limited but since April 1st first all receiving sites have been limited to 500Kbs not once have I seen it go higher, I have some pretty powerful computers with 50Mbs FIOS so there is no reason for the limitation other than a problem with server setup or it being done on purpose.

Its not our equipment or connections

Health% are always at 100 percent and no dropped frames too.

So where is the setting in the Microsoft Silverlight client
Log shows webcast receive starts out at 2048Kbps, but then it steps down to 500Kbps
..Manifest::Bitrate::2048Kbps
..State::DownloadProgress::1
..Info::MinBitrateSelection::100
..Info::MaxBitrateSelection::500

mikevandre wrote:In my tests of the new webcast system (portal.ldswebcast.org) I've noticed that by default the system is setting the receiving feed at a very low bitrate (100KBps). This is even the case when doing a test receive webcast. If I manually set the min bitrate to 500 KBps however it jumps up the higher quality and has no issues at all receiving at that rate. Do most of you let the system decide your minimum bitrate or raise it up because of this issue? Also we noticed in our full test broadcast today that some sites have 1024 KBps connections but some one site had a max of 500. This was a building that had above average bandwidth. Why would this be? What determines the max bitrate?

And lastly, what is the stabilizer setting on the receiving streaming site (Defaulted to 1) and what do the red line and green light represent in the graph on the left?

I didn't see an answer to your question about the red and green lines but I think the red line is the current display bitrate while the green line is the current download bitrate.

I did not see an answer to the question about what the stabilizer does, but changing it has not done anything that I can see.

I have tried to set the min bitrate to the highest value to see if that keeps it from going to the low 100kpbs display rate. Has anyone received specific instruction how to set these?

Also, I sometimes see a penalty value, most recently it was 300. That is that?