Bitrate switching and RTMP/Limelight

 
Your server does not appear to support bitrate switching.

Compare your track to the FMS v3.5 track in the Longtail Video example bitrate switching playlist. Your server does not switch the bitrate when toggling between fullscreen and normal.

Ahhh...this is interesting! Seems that my server does support bitrate switching. Here's what I'm seeing.

If I load the page fresh, and my stream plays first, the detected bandwidth starts at about 5000kbps, but the chosen stream is 64k. The bandwidth then changes wildly, going up to ridiculous numbers, then down to 50 or even 0, then back up several times over the course of a minute or two. If I leave it plauing long enough, it will eventually switch up to the 384k stream. But it won't stay there long, as the bandwidth will dip back down to less than 100 for long enough and the stream then switches.

Now, if I play your element in the playlist (just by clicking the button on the player), the bitrate stays stable beween 10000 and 20000kbps, and the stream stays on the 800kbps.

Here's what's really odd -- if I now switch back to my stream, the bandwidth stays stable and it plays the 384 stream right from the beginning, and stays there for as long as I play. So playing your stream first makes my stream work right.

?!?

 
Interesting!

I wonder if the Longtail Video FMS server is setting something in the player, which then makes the bitrate switching work.

As far as I know, there aren't any other flashvars to set for bitrate switching.

Maybe Jeroen or one of the other developers can give us some insight into this behavior.

One of the problems with measuring the available bandwidth, is that by it's very nature, bandwidth on the Internet varies wildly. Taking a rolling average works fairly well, but that takes time and everyone wants the video to start playing instantly at the optimum bitrate.

I think I can describe what's happening here.

The problem is, at least in this case, that the first choice can't be the one that's picked. If I take my original media:group like this:

...and play it in a 480-width player, the first item evaluates true, and the behavior is what I described: QualityMonitor says it's chosen stream 1, but stream 4 is what plays; and the bitrate detection is all over the map and the switching doesn't work right.

But, if I add a new first choice and make it deliberately bogus:

...then it correctly chooses and plays the second item, and the bandwidth detection numbers stay stable and reasonable, and if I throttle the network bandwidth, the switching works. It does not matter if the first choice is not chosen because I set a too-high bitrate, or a too-high width. Either one evaluating 'false' will make the other options select and play correctly.

              [i]AWESOME![/i]

Something is "buggy". But that's a good workaround for now.

It even makes bitrate switching work on the Red5 RTMP server where I had given up all hope!

You might want to screw around with this Test Page a bit, the video changes as you change the player's display size. Your playlist, Longtail's playlist, and a couple of mine are selectable.

http://willswonders.myip.org:8074/Simple_bitrateSwitchingRTMP.html

FANTASTIC

@ LarryB: this might be fixed in the latest version of the 4.x player. This version will force check on startup which bitrate to use.

Out of curiosity: do you use dynamic streaming?

Jeroen, I'm using 4.6.485. Is the issue fixed?
I'm using Wowza 1.7 with BWCheck plugin.
Digging into it I see that:
1) When starting playing - 5000 kbps is always displayed (without any measuring)
2) JW Player does not request bandwidth measuring when connecting. It does it much later.

Can you say something about it?

If you pull the player from trunk right now, the issue is fixed. The player didn't want to "switch" from the first to the first video on startup.

And indeed, it takes about 2 seconds after starting the video before the bandwidth is sniffed. That's a delay in the player >< server communication though. Only after this sniffing has completed, the player will select the bitrate to play.

Jeroen, thank you.
Can you point me to this "trunk", because I'm looking at http://developer.longtailvideo.com/trac/browser/tags/mediaplayer-4.6
..and player.swf has this info:
8 weeks jeroen: made pause button for livestream also stop the stream.
Or, do you mean that JW Player 5 supports bitrate switching now?

Here it is:

http://developer.longtailvideo.com/trac/browser/trunk/as3/

Got it, Jeroen! )
Can you also say something about why JW Player 5 does not work with Wowza that has BWCheck module installed? It initiates bandwidth checking, but stops playing the video after bandwidth measuring response is got. Or am I doing something wrong?

Could I get the licenced version of the latest 4.7 (as given above). I have 4.6 licence and I have 4.6.485 - bit rate switching is not working with Wowza 1.7.2 or 2.
Thanks

@romanbatkowich: Development of JW5 began before bandwidth switching made it into JW4. It is top priority for JW5.1.

@rajan - You can pick up the latest version of JW4 from http://developer.longtailvideo.com/trac/browser/trunk/as3/.

Thanks, Is bit rate switching not functional in 4.7?
Can I download the full licenced version of 4.7 from the above link?

When would 5.1 be out?

rajan, I guess you should look here..
http://developer.longtailvideo.com/trac/roadmap

Thanks. I will check it.

Jeoren,

In response to "Out of curiosity: do you use dynamic streaming?":

Yes...we're streaming rtmp from FMS 3.5 via Limelight. Dynamic streaming works in this environment with the 4.6.485 player.

Larry

It looks the one way to get JWPlayer to work correctly with bitrate switching is to include a video with a bitrate extremely large...

Is there any updates on dynamic bitrate switching with Wowza 2. Has anyone tested 5.1 with Wowza 2. Thanks.