JW Player Buffering Sucks

As you might have found out by now, it is not the player but the protocol that's the issue. This site uses RTMP, which is a protocol that indeed maintains a small videobuffer instead of downloading the video.

I have actually been part of a team that wrote a very non-trivia streaming media browser plug-in, so I am saying the following with some authority.

There is no way that the server or the protocol or an act of god can prevent the player from buffering an arbitrary amount data when I hit "pause" because the player can simply "pretend" it is playing all the way to the end regardless of what is being displayed.

Well behaved players (Google, YouTube etc.) keep _all_ the frames - already played and not-yet-played - in some buffer so it is possible to freely seek around and re-play parts without contacting the server.

There is no technical reason not to allow for this. There is also no security issue with it.

First, you don't need to make this buffer be accessible, nor does it have to be a playable FLV file (you can mess it up any way you want). So even if the user could grab this hidden buffer file, it would do him little good.

Second, as long as you don't do public-key handshake and key-exchange and encrypt all the packets, there are a zillion free "FLV downloader" utilities that simply write each frame to the disk as it is played, proving both the technical feasablity of allowing buffering and seeking, as well as the futility of trying to protect the content from being copied.

Bottom line, it makes no sense to place a timed-delay-lock steel door on a shed that has its windows wide open :-)

Any more feedback on this from Jeroen or anyone else? We recently upgraded from an older version of JW to the latest and also are now streaming via RMTP off of a Wowzamedia server. For guys like me with fast connections, it's working great. We are getting a lot of complaints from users that the video is chopping around, pausing/restarting a lot, etc. I would assume that they have a slower connection and that it is not buffering properly.

With the old setup we had, they could click play/pause, let it buffer, click play and be good to go. Now since it's "streaming" (and apparently not buffering at all), they're SOL.

Any suggestions?

I have terrible problems with the latest version of the player. My mp3's no longer play correctly, getting an error 2032 and if I'm lucky I get about 10 seconds of my tracks to play. I bought a license for this player (even though I don't actually need it yet) as I was/am happy to support it because previously it's been excellent. For the first time with this player there appear to be problems beyond my control, unless I'm missing something obvious. I don't know what to do!! Any ideas? Cheers.

Just for information purposes here related to Kevin Ace post, I have the slowest adsl broadband connection, it's all thats available as I'm right at the tail end of the exchange with no options for cable either.

Cheers.

@Oren / @KevinAce:

The stuttering of video when having a slow connection is simply a result of how RTMP streaming is set up. With RTMP (FMS, Red5 & Wowza), the server streams video to the client until the buffer (usually a few seconds) is filled. It will never load more data than the length of the buffer. So when you have a small bufferlength and a barely-enough connection, the video will stutter. The bufferlength is 1 second by default in the JW Player and can be changed with the "bufferlength" flashvar.

Services such as Youtube or our own BitsontheRun use HTTP streaming instead of RTMP streaming. The big advantage is indeed that the video IS being loaded ahead, so you can wait for a while until enough video is loaded and then watch it entirely without stuttering. Obviously this is a big advantage of HTTP streaming over RTMP.

The JW Player can do both types of streaming; RTMP with FMS, Wowza and Red5 and HTTP streaming with simple ASP/PHP scripts (such as XMoov PHP) or servers such as Lighttpd/NginX. My personal favourite is HTTP as well, due to this streaming/buffering problem and due to the fact that it is so easy to set up. RTMP on the other end is better protected, which is of course important for specific types of content.

@Adrian Judd:

This seems to be unrelated to the stuttering issue. Do you have an example page to check? There's been no recent changes in the MP3 playback API, so there might be something else going wrong here.

Hi Jeroen!

Does that mean that with HTTP streaming it is generally impossible to start at an individual point within the Video that is not yet loaded/buffered/read ahead?

Ist ist only possible with RTMP to jump to an individual location in the video and "fetch byte ranges"?

Or in other words: Does viewing a FLV video start immediately with HTTP streaming independently of the underlying server technology as it is the same as a download?

Ben

Sorry, found the answer:

http://www.longtailvideo.com/support/tutorials/HTTP-Video-Streaming

If people refused to use this piece of junk maybe it will slowly die? I certainly hope so.

Why do people still use RTMP?! people with slow connections are going to have issues! use advanced progressive download for your videos, you still get the same features as RTMP (if not more) and can maintain security if you need too.

I agree with Oren totally. I think JW sucks if it can't buffer. For now I have to UL to YouTube and embed so at least that way my users can watch the video without the stutter. wish this player acted like youtube player. Unfortunately YouTube kills the quality.

one more thing. glad i tried it before buying a license.

My problem with buffering is related to the 4.3 player and http buffering, no matter what I do there are issues, I have tried different bufferlenght setting. Sometimes the video starts, plays for a few settings, then stops. Sometimes it starts playing with only video. Sometimes I have to press play over and over again to get it to play. The only way to get it to play the entire video is to let the whole clip buffer (but i cant see any indicator showing how much is loaded?)

I have reverted to the 3.15 player, which plays the same video well, without the same issues.

I am not playing .flv files, the files as delivered through a script.

JeroenW,

FMS server supports something called Dynamic Streaming, in support of multibitrate streaming. Why not support this in your player so the server can cut the bits out based on detected connection.

Here is some info from Adobe.
http://blogs.adobe.com/ktowes/2008/11/

Your player is great, I just wish it handled dynamic streming!!

@scott: the bad quality of YT is the only reason why it doesn't stutter with you. YT uses exactly the same buffering method as the JW Player.

@Morten: I think the script is the issue. The 3.xx player was built in actionscript2, which is less restrictive in terms of URL requests / headers. Can you take a look at whether your script sends a response header with the filesize of the video?

@Bill: FMS dynamic streaming support is indeed on the todo list for the player. Beware though that FP10 is needed for this feature - about 50% of people have that installed now.

JeroenW,

Thanks for the update. I really look forward to dynamic streaming. This will solve so many issues for so many people. Okay that player version 10 is required. I am glad to force consumers to get it. That is much better than stuttering video playback.

Again, your player is great. With dynamic streaming it will be even better.

Bill

Hi guys
I have seen so much of your problems and solutions. I am using the JW player through javascript. I have a small problem that while playing the content it's not buffering the file. when I move the cursor it start streaming again. can we make it happen that only one time it reads from source and it buffers the content while playing. like you tube player do...here is my javascript code.

s1 = new SWFObject("swf/player.swf", "songPlayerId", "300", "220", "9", "#336699");

s1.addParam("allowfullscreen","true");

s1.addParam("allowscriptaccess","always");

s1.addVariable('file',theFile);
s1.addVariable('streamer','rtmp://localhost/indiemusic');
s1.addVariable("width","300");
s1.addVariable("height","220");
s1.addVariable("displayheight","220");
s1.addVariable("autostart","true");
s1.addVariable("repeat","list");
s1.addVariable("controlbarsize","5");
s1.addVariable("playlistsize","50");
s1.addVariable("enablejs","true");
s1.addVariable("javascriptid","songPlayerId");
s1.write("placeholder");

can we make it solve by adding any variable in the code. please do help me.

if you want buffering behavior like youtube, you should use a lighttpd or nginx server, not rtmp

Hi joey,

Thanks for you reply. But do you thing that switching the server or changing the protocol is the only solution we have. I have tried to playing content through http instead of rtmp than the problem solved.but in that case red5 also doesn't comes in scenario and some how our requirement is kind of that we need a media server in between to play the contents. If you do have any solution for this than please do help me and if not than please provide some description about --"why we can't solve it using rtmp"

One solution (which we've used on a proprietary FLV player written in-house), and works fine with RTMP, is to dynamically track and adjust the buffering.

The NetStream object provides events that fire when the buffer is full and when it is empty.

The player we wrote records the time at the start of the stream and calculates how long it takes to fill the buffer, giving an initial estimate of the connection speed of the user. If the calculated connection speed is too slow, it does one of two things:

a) Switches to a different file with lower quality (if available -- specified in the XML file for that video) or

b) Automatically increases the size of the buffer.

If, during playback, the buffer empty event is fired again, the average connection speed is recalculated. At this point, an even slower video is picked (if available) or the buffer size is dynamically increased again.

It would be terrific if such a solution were applied to the JW Player. Stream switching would require the users upload multiple qualities of the video -- don't know how many people would want to do that. But the dynamic adjustment of the buffer size shouldn't be too hard to implement and would totally solve this problem.

Progressive download doesn't have this problem, but it isn't necessary to eliminate RTMP if a dynamically calculated buffer is used as above.

JK

Thanks buddy, let me try this and will let you know if found any solution.

When adding the "bufferlength" flashvar, do you do it by:

(a) s2.addParam("bufferlength","900");
or
(b) s2.addParam("flashvars","bufferlength=900&file=<?=$video_key?>&streamer=rtmp://<?=STREAM_DOMAIN?>/simplevideostreaming&type=video");
?

And of course just ignore the extra variables I have in (b)

bufferlength is a JW FLV Player flashvar NOT an Adobe Flash Player parameter.

So it's:

Any update on when Adobe Dynamic Streaming will be implemented?

I need to get this implemented and I would prefer not to switch players. I like this one, just have this one issue that Adobe Dynamic Streaming is not supported.

Bill

I'm told on another forum that you can increase the buffer size (not the same as buffer length discussed above) in the player, possibly by modifying the original source:

netstream.setBufferTime(3);
or
netstream.bufferTime = 3;

I'd like to increase the buffer size so when you pause the video, it will load at least 5 more seconds, or even the entire video, so people on slower connections can let the video load, though I'm using RTMP with Wowza as well. Is this possible?

If so, which file do I modify? And can it be done without modifying the original source?
Through a flashvar?

I'm dropping JW Player and converting all my FLVs because of this issue. I was almost willing to buy a license. JW, I hope you can figure out a workaround soon...

Im having problems with buffering through http progressive download. I'm using the h264 streaming module found here:
http://h264.code-shop.com/trac/wiki

with apache.

I SWEAR jwplayer is doing some type of bandwidth throttling, because when I pause the playback of the video, it buffers REAL fast. If jwplayer is not doing bandwidth throttling, then im at a loss, because the author of the module hasn't implemented bandwidth throttling yet for apache.

I've played with the bufferlenth var to no avail! help!

dropping the player too ...

yeah.. i'm getting rid of the player as well .. it's good for basic stuff .. but not really good for production.

I just got the bitgravity CDN.. buffering is still horrible on some computers.... Cant for the life of me figure out where the issue lies.

Hey thanks JW adding "bufferlength" solved this for us, sweet
It's in milliseconds right =)

For this, and a few other players that don't cache the data when you hit pause, I end up leaving the site and going to youtube for a lower-quality but far less frustrating experience. I've had problems with all buffering players even on high-end connections. If I have a choice between having a few seconds of high-quality video at an official site or conglomerate site, which pauses and buffers, or something I can simply hit pause and let the whole thing load while it's going to be significantly lower quality, well, I'm going for the latter.

Anyone remember this company? http://i348.photobucket.com/albums/q321/EightOHonE/funny/buffering.jpg

Developing a new video player for the internet that works at a higher quality than YouTube while allowing such a simple feature isn't aiming high. What players such as JW Player are doing is aiming low, then screwing up even that and shooting their own foot.

Folks, it has NOTHING to do with JW Player, and everything to do with the way Adobe caches RTMP streams.

However, there is a *minor* set of changes that can be made to the JW Player that make it a little bit smoother. Using a dual-buffering technique described HERE: http://www.adobe.com/devnet/flashmediaserver/articles/fms_dual_buffering.html

and HERE:
http://labs.influxis.com/?p=4

One can achieve slightly better "buffering capabilities" over NET Connection object. However, the REAL problem lies with the implementation of NET CONNECTION / STREAM that Adobe compiles into Flash Players....
The answer is here: http://labs.influxis.com/?p=4
"Of course, there’s some bad news for buffering in the Flash Player: anytime you seek or pause the Flash Video clip, the entire buffer is dumped. If you’ve thought that you could buffer the entire video clip for slow connection speeds, forget about it–once the user pauses or seeks the video (if those operations are indeed permitted by your playback controls), then the user has to wait all over again for the buffer to refill."

Now, that said: as JW pointed out, you have a choice: change your FLV to SWF to download and use local cache, and then: change the format to "progressive download". Both of which expose the Intellectual Property to anyone looking at the web-browser temp cache directory.

Also, you could "conceivably" re-render your FLV to lower-quality, or re-render to variable bit-rate streams. Both change the way NETConnection in AS3 handles these components.

Unfortunately Adobe has not yet seen fit to "fix" these problems, which would be awesome if we could open "two" concurrent net-connection streams, and then have the player switch between them on demand. Just not possible. It would also be awesome if Adobe allowed NETConnection to "set minimum and maximum" buffer lengths.

@JW: in the mean time, I've had limited "decent" success by implementing the double buffering scheme within the RTMP streaming protocoll AND re-rendering my videos to a lower bandwidth and smaller playback size.

Cheers,
Dan Linstedt

Thanks, Daniel. I'll look into that. I wouldn't be surprised if you were completely accurate- Though I use Adobe Photoshop for a great deal of my work, their products have huge flaws that are seemingly never addressed, so I can readily believe this. Adobe Acrobat is a godawful program that, for all the updates in the past few years, never actually gets better. It's a bloated program with poor user interface and programming, so I can see how another software piece they've engineered acts as a sort of idiot savant, program-wise; it'll do a couple of things really well, but be utterly screwed up in every other aspect, often to the detriment of the point of the whole thing.

jw is shitty! bottom of the line! end of story!!!

Jw player run and never crash in 10 mounths.

we tryed it with progressive and RTMP protocol and always run without problem.

Http streaming seems good, but not so much SaS are on the market for offer it.

So RTMP is again the main street, for us

You're welcome. Here are a few more hints that affect "video" on the web:

1) bandwidth of the host where the files are being played back from
2) bandwidth of the routers/hubs/internal DNS on the company using the video
3) Security fire-walls that "check" the live stream as it comes in.
4) Video size and quality. A movie at 640x480 is smaller and requires less "bits per frame" than an 880x660 movie. Likewise, an Audio stream attached to the movie at 44.1khz and 96kbps will cause the video to run slower than an audio stream at 22.5k and 28kbps In other words, the audio is updated much more frequently than the video, lower quality audio requires less band-width. Higher quality audio requires more bandwidth, as does larger videos.
5) QuickTime format as opposed to Flash FLV or SWF can make a difference too - uses a different encoding algorithm. AVI is probably the largest "most full" format you can get, IF you use a loss-less codec. If you use a Lossy codec, you'll get "grainy video" in some cases, but you'll eat less band-witdh.

Again, it's not the player here folks.... It has everything to do with the playback, network, bandwidth, quality, file size, etc...

If Adobe continues creating "poor quality" components, they will be surpassed by Microsoft platform and it's effort to hit the market with Silverlight, but guess what... it suffers from similar issues when it comes to doling out video streams.

That's why high-speed (true video hosting) costs so much for bandwidth, they have to lease the bandwidth from the Telephone companies.

Hope this helps,
Dan L

Then what is the use of any Media Server? Can I use the progressive download method without any media server to get my videos play smoothly without buffering?

Sorry I am a novice.

I think it is pretty hilarious how the blame gets passed around. Oh "it's not JW Player!! It's Adobe!!" Are you kidding me? How long has Adobe been around compared to whoever makes that crappy JW player that stops playing every 10 secs? Give me a freaking break. It is one this to pass blame but it is another thing to underestimate the intelligence of a products market. It is comparable to calling a cell phone company when you lose a signal. It isn't ATT's fault it is YOUR cell phone. If someone has to learn tweaks and minor adjustments to get something to work well "which it should before the product is distributed" then there is a serious problem in general. Give people a break and don't insult people's intelligence.

Uhh I don't know what this user is talking about.

If the video is studdering its because there is insufficient video bandwidth being provided or your internet provider is too slow.

I second no-wait its a jw player buffering problem. I mean he wouldnt be complaining unless he ran the common sense test and so have i...

Can you provide a link to where the buffering sucks?

Does the JW player use anything like the dual buffering technique that Daniel Linstedt mentioned in his post? I've used the dual buffering technique in players I have built and it seems to work quite well.

Hi, all -

Jeroen has looked into implementing this in the past, and ran into some trouble with how it effected the way the player calculates its buffering state.

We're investigating implementing this, and we may implement this in a future version (not 5.1, which is too close to release). You can keep track of our progress with this ticket: http://developer.longtailvideo.com/trac/ticket/619

I will definitively be looking out for the DualStreaming addition!

I'd have to say the buffering limitation is absolute crap. Of the players i've seen and used jwplayer is the only one with this problem. I have a pretty decent connection and i still have trouble getting more then a minute or two to load with this player before it shows the buffer %. I've watched dvd quality video with other players online in real time, not waiting for a buffer, and had absolutely no problems. I suggest using any other player. Sometimes they require that you pause and allow it to load more before you can get a clean view but at least they don't pause every minute to load the next next minute.

If you need a site to post decent quality videos on try stagevu. They use the divx player which allows you to save what you've watched.