Some updates to RTMP bitrate switching

[jeroen]

Hi guys, just got back from our event which we used JW Player connected to Wowza for dynamic streaming. Initially we had quite a few issues with this but we managed to find an fix them all so wanted to contact you with the fixes we made so they can make it into the next version.

Fixes Made

• Added model variable "dynamic" which enables the user to override the FMS server version check for dynamic streams. Functions: checkDynamic & statusHandler
• Fixed level checks, the initial level being set didn't necessarily agree with the level being used which caused problems when switching levels. Function: load
• Enhanced the checks that determine if a switch to a different stream is possible / needed. This still needs improving for the switch up with the addition of both historical information and CPU if possible. Function: getLevel
• Fixed transition complete event processing. It seems like this was never being done, the result being multiple transitions never occurred only the first one. Function: statusHandler

[jeroen]

Patch with the changes made

[jeroen]

The dynamic flashvar looks fine to a certain extend, but it'd be nicer if Wowza could send a version number as well so it'll just work for guys. Setup of RTMP streaming is already insanely complicated when compared to HTTP, and adding yet more flashvars doesn't make things easier. Have to contact Wowza on that...

[jeroen]

The level check on load makes a lot of sense. Added that in. However, later on we should make sure the switching by itself will work independently of the state of the "file" flashvar.

[jeroen]

We tried to stay away from complex upswitching / downswitching switches like the one proposed. I understand the 150 kbps buffer either way is - in theory - a good thing. However, in practice someone's bandwidth is either way off or crazy fluctuating, which renders code like this entirely obsolete.

That's also why the JW Player has no CPU stress estimation: it's also very unpredictable. For example, your bitrate might switch down because your email client is pulling in some files.

[jeroen]

The transitionComplete event is actually an interesting one. I expected we had to listen for it to know if a transition occured. That turned out to not be the case though (in the case of FMS 3.5). Not sure why this event fired, but it seems pretty unrelated to switches actually being succesfully performed.

The NetStream.Play.TransitionComplete callback actually is the right one to listen for when deciding if a switch happened.

Again, this is in FMS3.5. It'd be great though if Wowza would fire the same callback, since listening for the event instead of the callback results in strange switching behaviour on the FMS3.5 side.

[jeroen]

The stream switching issue is more one of jumpy max_bandwidth info calls than of the switching mechanism itself. Might be best to look into the bandwidth calculations for this.

[jeroen]

Added a little switch for averaging out the bandwidth:

if(bdw < 100 || bdw > 99999) {
	return;
} else {
	bdw = Math.round(model.config['bandwidth']/2+bdw/2);
}

Values that are out of bounds will be ignored, values that are in bound will be averaged with the current BW.