JW Player Buffering Sucks

39 posts | return to the Bug Reports forum | get the rss feed for this thread

Dec. 13, 2008Oren

I stumbled upon http://videolectures.net/mlss07_rasmussen_bigp/ which uses JW Player.

But trying to watch the videos is like having my teeth pulled. Slowly.

The problem is that the bandwidth I get off the site is just _almost_ enough for real-time streaming.

In any other player (e.g., the one used by YouTube or Google Video), that's no problem. I start to play (so it will start downloading), hit pause, let the buffer grow to whatever size I want (even the whole full hour for a Google video!), and then can watch it without nasty interruptions.

But JW Player seems to have the *nasty* restriction that it will not keep a lookahead buffer beyond some ridiculously small size. That means that I can watch about a minute of video, then the buffered data percent plunges to zero, the video stops, the buffer grows back to 100%, the video resumes, plays for a minute, and the whole cycle starts again.

This user experience *sucks*.

I have no idea why JW Player acts in this brain-dead fashion, but it is enough to make me do one of two things - either (1) avoid any web page using it like the plague, or (2) if I really want to see that content, figure out a way to download it to my hard disk using any of the zillion work-around-stupid-download-restrictions programs out there.

Neither seems to be in the interest of the content owners (who are, I assume, your paying clients).

Dec. 18, 2008JeroenW

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.

Dec. 19, 2008Oren

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 :-)

Jan. 21, 2009KevinAce

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?

Jan. 22, 2009Adrian Judd

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.

Jan. 22, 2009Adrian Judd

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.

Jan. 24, 2009JeroenW

@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.

Feb. 10, 2009Ben Jencke

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

Feb. 10, 2009Ben Jencke

Sorry, found the answer:

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

Feb. 23, 2009TomM

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

Mar. 02, 2009Data

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.

Mar. 04, 2009scott

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.

Mar. 04, 2009scott

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

Mar. 15, 2009Morten Skogly

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.

Mar. 24, 2009Bill

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!!

Mar. 26, 2009JeroenW

@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.

Mar. 26, 2009Thanks!!

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

Apr. 14, 2009Anirudh

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.

Apr. 14, 2009joey

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

Apr. 15, 2009Anirudh

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"

Apr. 18, 2009Jeffrey Kretz

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

Apr. 19, 2009Anirudh

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

Apr. 23, 2009beyondthegrave

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)

Apr. 23, 2009brokenString

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

So it's:
...swfobject v2.x
'bufferlength':, '900',
...or SWFObject v1.5
so.addVariable('bufferlength', '900');
...or SWFObject v1.5
so.addParam('flashvars', bufferlength=900&...



Apr. 27, 2009Bill

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

Apr. 30, 2009beyondthegrave

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?

May. 29, 2009TGMaster

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...

May. 30, 2009floz23

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!

Jun. 21, 2009highlander

dropping the player too ...

Jul. 27, 2009flint

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

Aug. 12, 2009floz23

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.

Sep. 01, 2009Nick Doyle

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

Sep. 15, 2009Fed Up

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.

Sep. 16, 2009Daniel Linstedt

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

Sep. 17, 2009Fed Up

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.

Oct. 27, 2009jw shit!!!!!!!!

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

Oct. 28, 2009nexus6

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

Oct. 28, 2009Dan Linstedt

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

Nov. 16, 2009Krish

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.

Add a reaction

You can also return to the category or try this search for related threads.

Your name *

Supported codes:

 

submit