<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>Streaming and (very) inefficient bandwidth usage</title>
		<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage</link>
		<description>LongTail Video forum thread: Streaming and (very) inefficient bandwidth usage</description>
		<ttl>60</ttl>
		<language>en-us</language>
		<copyright>some rights reserved (cc)</copyright>
		<pubDate>Sat, 21 Nov 2009 06:23:14 -0500</pubDate>
		<lastBuildDate>Wed, 23 Sep 2009 10:40:34 -0400</lastBuildDate>
		<atom:link href="http://www.longtailvideo.com/jw/rss/?thread=8715" rel="self" type="application/rss+xml" />
		<item>
			<dc:creator>aneeshanand</dc:creator>
			<title><![CDATA[hi JeroenW Did you fix these issues in version 4.5? ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg131921</link>
			<description><![CDATA[hi JeroenW

 Did you fix these issues in version 4.5? ]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg131921</guid>
			<pubDate>Wed, 23 Sep 2009 10:40:34 -0400</pubDate>
		</item>
		<item>
			<dc:creator>onerob</dc:creator>
			<title><![CDATA[Wasn't JohnDoe's original point that the JW Player woul ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg105549</link>
			<description><![CDATA[Wasn't JohnDoe's original point that the JW Player would send a new http request even when clicking within a buffered segment of video?

Has this been fixed?]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg105549</guid>
			<pubDate>Tue, 27 Jan 2009 06:22:28 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JeroenW</dc:creator>
			<title><![CDATA[The 2032 security error is easily explained: the player ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg85571</link>
			<description><![CDATA[The 2032 security error is easily explained: the player doesn't know which filetype to expect and presumes you load a playlist. Hence, please add .flv

As to the buffering, I'm afraid this is simply how the RTMP system works. Data is loaded until the buffer is filled and then the loading stops. YouTube (and HTTP streaming) indeed continues loading even when paused. I am working on two enhancements that might fix this:

1. Dual buffering: once the initial buffer is filled, the bufferlength is set at a higher value.
2. Bandwidth switching: next to the high-quality video, you can add a Lo-Q one and switch between the both depending on your bandwidth.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg85571</guid>
			<pubDate>Thu, 11 Sep 2008 10:58:31 -0400</pubDate>
		</item>
		<item>
			<dc:creator>cyber</dc:creator>
			<title><![CDATA[I see, pausing will not buffer the next parts like yout ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82779</link>
			<description><![CDATA[I see, pausing will not buffer the next parts like youtube? how youtube streams is excellent, perhaps a feature like this can be implemented? it will be so helpful for users with slow connection especially since most people are more familiar with how youtube streams.

I see the buffering icon quite a lot as well, although this is only true for videos that are very big, i have the bufferlength set to 5... I don't know but im annoyed at the buffering icon's frequency:
1. Buffer Load to 100% (5 seconds)
2. Movie Plays for 5 seconds (While playing im still seeing the buffering percentage, but it is going down until 0%, maybe it's just me but whenever the percentage goes down to 0% that's the time the 5 second buffered has already reached the last second as well.)
3. After the buffered 5 second is finished it loads until 100% again and rinse and repeat... the buffer icon is there forever.

Try loading a big movie and perhaps you can recreate this. This could be answered with the feature: buffering while paused, since everyone is used to how youtube works.

btw, 
JeroenW, your player is so darn excellent and great... It's a dream come true, keep up the good work! This is the only feature missing, hope it's possible =)]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82779</guid>
			<pubDate>Thu, 21 Aug 2008 23:21:28 -0400</pubDate>
		</item>
		<item>
			<dc:creator>kLink</dc:creator>
			<title><![CDATA[@JeroenW,I see the buffering icon quite frequently  ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82651</link>
			<description><![CDATA[@JeroenW,

I see the buffering icon quite frequently when using RTMP from my own Red5 server over a 1Gb LAN and I see it on many RTMP streams from FMS. The videos can be short (10s) or long (2hr).

I also have noticed that recent versions like v4.1.60 will give a 2032 Security Sandbox error if the filename doesn't have an extension and you don't specify a type of 'video'.

Try this RTMP stream:[code]
streamer:             'rtmp://flv.williams.edu/streams/media',
file:                 'obrecht/obrechtmp4s/wny',
type:                 'video',

[/code]I'll collect some more RTMP streams that buffer frequently and post them.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82651</guid>
			<pubDate>Thu, 21 Aug 2008 10:21:14 -0400</pubDate>
		</item>
		<item>
			<dc:creator>JeroenW</dc:creator>
			<title><![CDATA[I think there's two issues here:1) The behaviour of ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82629</link>
			<description><![CDATA[I think there's two issues here:

1) The behaviour of HTTP streaming: downloading will continue even while the video is paused and when seeking to nondownloaded parts the previous buffer gets cleared.

This is really how HTTP download works. Check Youtube, or other players, they'll do the same. It's practically impossible to have multiple downloaded parts in buffer, and the loading-while-paused is actually handy for people who have a slow connection but do want to see the HiQ video.

2) The showing of a buffericon with RTMP servers.

This is a bg and shouldn't happen. I've never encountered this though. cyber, kLink, can you give more info? Are these videos very short? What RTMP server do you use? Are the videos very HiQ?]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82629</guid>
			<pubDate>Thu, 21 Aug 2008 09:39:22 -0400</pubDate>
		</item>
		<item>
			<dc:creator>kLink</dc:creator>
			<title><![CDATA[Temporarily, you can get rid of the annoying loading ic ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82436</link>
			<description><![CDATA[Temporarily, you can get rid of the annoying loading icon by setting bufferlength=null in your player code.

Yeah, we all hope this gets fixed soon... :)]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82436</guid>
			<pubDate>Wed, 20 Aug 2008 11:05:00 -0400</pubDate>
		</item>
		<item>
			<dc:creator>cyber</dc:creator>
			<title><![CDATA[Likewise here.this is so bugging me as well, i've f ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82434</link>
			<description><![CDATA[Likewise here.

this is so bugging me as well, i've finally got an rtmp server and the buffering makes the video unbearable to watch... Does it really work like this? ... i mean i have a bufferlength set to 5, whenever i play the video it waits for 5 seconds then after it got loaded 100% it would play for 5 secs while the load % is still there decreasing until 0% then loads again, rinse and repeat. shouldn't it load continuously? It seems to only start loading again after it got back to 0%.

Load until 100%... Plays (while % decreases as well)... then when the % goes back to 0 it's only then that it starts loading again... this is quite annoying, is there any fix for this?

i've paid for the unlimited website license btw and i hope this gets fix soon as im running the player on a video-on-demand pay per minute business of mine.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg82434</guid>
			<pubDate>Wed, 20 Aug 2008 11:02:36 -0400</pubDate>
		</item>
		<item>
			<dc:creator>RogeR</dc:creator>
			<title><![CDATA[Yeah, I noticed the issue is still not fixed also.. JW  ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg76342</link>
			<description><![CDATA[Yeah, I noticed the issue is still not fixed also.. JW is such a great player, but I wish this streaming issue was fixed.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg76342</guid>
			<pubDate>Fri, 18 Jul 2008 16:16:12 -0400</pubDate>
		</item>
		<item>
			<dc:creator>Thomas</dc:creator>
			<title><![CDATA[The inefficient bandwidth usage has not been fully corr ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg72716</link>
			<description><![CDATA[The inefficient bandwidth usage has not been fully corrected in version 4.0.

When I hit the pause button, I see that the buffer still gets filled up. However if I do scrub in a portion of the downloaded video it doesn't make a new request to the server, but anyway it was still being downloaded, so it didn't change much.

I also noticed that if I scrub outside of the buffer, then the previous buffer gets cleared.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg72716</guid>
			<pubDate>Thu, 03 Jul 2008 08:25:59 -0400</pubDate>
		</item>
		<item>
			<dc:creator>JeroenW</dc:creator>
			<title><![CDATA[One issue has been addressed - if you pause and replay  ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg54693</link>
			<description><![CDATA[One issue has been addressed - if you pause and replay the movie it won't rebuffer. The other parts indeed aren't done yet. I'll add that to the 4.0 player.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg54693</guid>
			<pubDate>Sat, 23 Feb 2008 12:45:01 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Hi JeroenW,I noticed that this issue hasn't been ad ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg54689</link>
			<description><![CDATA[Hi JeroenW,

I noticed that this issue hasn't been addressed in the 3.15. 

I particular the player still doesn't make any use of the buffered parts nor it shows it somehow in the download bar.

Is this issue still on the road map?

Cheers.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg54689</guid>
			<pubDate>Sat, 23 Feb 2008 12:16:13 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JeroenW</dc:creator>
			<title><![CDATA[Yes, I consider this a bug too, and it'll be fixed with ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg52414</link>
			<description><![CDATA[Yes, I consider this a bug too, and it'll be fixed with the next update. Like with YouTube, the next update will show exactly which part of the video is in memory.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg52414</guid>
			<pubDate>Tue, 05 Feb 2008 09:23:21 -0500</pubDate>
		</item>
		<item>
			<dc:creator>ScottR</dc:creator>
			<title><![CDATA[Totally, my analysis of the Flash code is that the ligh ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51927</link>
			<description><![CDATA[Totally, my analysis of the Flash code is that the lighttpd streaming was to an extent hacked in (sorry for the harsh word, your product rocks and is amazing), and just loads the full bar because that enables the user to click where they want. After all it is much easier to just send through a request every scrub instead of calculating the buffer and using it to determining how the scrub will work

Hopefully this is something that will be changed, because it will certainly make a massive difference functionality and performance wise, if users can actually accurately watch the buffer and scrub to it without a wait.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51927</guid>
			<pubDate>Thu, 31 Jan 2008 14:01:20 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Yes YouTube, this is an interesting and useful possibil ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51905</link>
			<description><![CDATA[Yes YouTube, this is an interesting and useful possibility. Thank you for pointing me at that thread, I will surely play a bit with that "chapterization script".

However, I still strongly think JW Player should support the YouTube-like behaviour.

Cheers.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51905</guid>
			<pubDate>Thu, 31 Jan 2008 11:47:54 -0500</pubDate>
		</item>
		<item>
			<dc:creator>YouTube</dc:creator>
			<title><![CDATA[Actually, YouTube is probably a poor example to use bec ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51769</link>
			<description><![CDATA[Actually, YouTube is probably a poor example to use because most of their videos are short and users probably don't scrub forward of the download point too much. If you haven't watched the video once, why would you be scrubbing forward.

And once you have watched the video, the scrubbing takes place locally, out of the browser's cache.

However, many of the videos that I see user's of the JW Media Player making available, are quite long and are frequently accompanied by other material that may encourage the user to scrub forward of the download point (educational material, religious sermons, etc.). Of course, if it's a progressive download, they can't scrub forward of the download point. However, using streamscript with the PHP script or lightppd, they can scrub forward and then may later scrub back to the beginning.

The ideal situation would be RTMP supporting a "buffer full" command which would then stop the stream until the buffer was partially empty.  The other almost ideal solution is to break the long video into chapters in a playlist and only request the chunk for the chapter. The video file itself is NOT split, the requests are made for only a chunk of the full file.

That is implemented in the chapters scripts in this thread: [url=http://www.jeroenwijering.com/?thread=6080#msg33286][b]Chapterizer - Town Meeting[/b][/url]. There are two advantages to this method: one, only the chapter chunk is downloaded, limiting traffic unless the user selects another chapter, and two, if the user selects a previously viewed chapter, it comes out of the local cache instead of being downloaded again.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51769</guid>
			<pubDate>Wed, 30 Jan 2008 15:48:07 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[YouTube,It depends on how and where you scrub to, a ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51738</link>
			<description><![CDATA[YouTube,

It depends on how and where you scrub to, and what portion has already been downloaded/buffered by the player.

I invite you to try this:

1. Go to a YouTube video
2. Put it in pause and WAIT for a while until it downloads few seconds/minutes ahead (look at the red progress bar!)
3. Then scrub to a position WITHIN the dowloaded red area.

If yuo do this, you will notice that no additional http requests nor downloading take place. (If the player hasn't yet downloaded the whole video, it will simply carry on with that.)

On the other hand, if you scrub to a position which is BEFORE the point you jumped on sometime earlier, or if you scrub to a position AFTER the buffered area (BEYOND the red progress bar), only then YouTube looses the buffer and starts downloading. Again, the red progress bar tells it all!

It is true that you can have YouTube generate more traffic that the actual length of the movies. It can be double, triple, quadruple, or just any possible multiple of it, if that's what you want. 
In fact, I was not saying that YouTube is /perfectly/ optimal, but only that it is reasonably efficient with statistically predominand users behavour (people aren't scrubbing-junkies randomly jumping at random positions just for the sake of it, but they do the scrubbing for some purpose, and that gives birth to statistically more stable patterns of behaviour) and taking into account the size of Youtube videos.


However, all my previous points stand, as the JW Player doesn't do the kind of traffic-wise buffering as that of YouTube, I descrbed before (call it the red-progress-bar-way).

Stay well.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51738</guid>
			<pubDate>Wed, 30 Jan 2008 13:04:40 -0500</pubDate>
		</item>
		<item>
			<dc:creator>YouTube</dc:creator>
			<title><![CDATA[[quote]Indeed, as you correctly point out, "fake stream ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51670</link>
			<description><![CDATA[[quote]Indeed, as you correctly point out, "fake streaming" doesn't at all mean no-buffering, and that can easily be seen in YouTube and Google Video (and hey, if they do it this way, they must have made their calculations well, sice you should have in mind YouTube's traffic running costs:[/quote]

I don't think so...

Every time that I scrub in the YouTube player, it initiates a download. After multiple scrubs, there are many [b]get_video[n][/b] files in the browser's cache. For a 2,201KB video, this is what is in the cache:[code]get_video[1]     485KB
get_video[1]   1,467KB
get_video[1]     857KB
get_video[2]   1,846KB
get_video[1]   2,201KB[/code]looks like total traffic of 6,856KB and I can see that much traffic on my traffic monitor also. That's [b][i]TRIPLE[/i][/b] the size of the video file.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51670</guid>
			<pubDate>Wed, 30 Jan 2008 09:15:38 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Hi ScottR,Thank you for your feedback.Indeed, a ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51639</link>
			<description><![CDATA[Hi ScottR,

Thank you for your feedback.

Indeed, as you correctly point out, "fake streaming" doesn't at all mean no-buffering, and that can easily be seen in YouTube and Google Video (and hey, if they do it this way, they must have made their calculations well, sice you should have in mind YouTube's traffic running costs: here's a somewhat old but still striking estimation:
http://willy.boerland.com/myblog/youtube_bandwidth_usage_25_petabytes_per_month ).

Furthermore, as I explained before, some other free players, like FLV-Scrubber, supports that kind of behaviour.

I'm not an expert in Flash development, but my guess is that this is something that shoudn't be too difficut to implement (and it is of a crucial importance for any medium to large-scale deployment of JW-based httpd streaming).]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51639</guid>
			<pubDate>Wed, 30 Jan 2008 05:50:47 -0500</pubDate>
		</item>
		<item>
			<dc:creator>ScottR</dc:creator>
			<title><![CDATA[JohnDoe I agree entirely with all points raised in this ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51502</link>
			<description><![CDATA[JohnDoe I agree entirely with all points raised in this thread. I always thought this was a limitation of "fake streaming" but if the JW player could show what is buffered and then allow you to skip to the buffered section without restarting, that would be an amazing fix both bandwidth wise (much less usage) and speed wise (no rebuffering / server request).

Is this possible? I thought fake streaming meant JW player doesn't know how much of the video has loaded and therefore has to reload every scrub?]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51502</guid>
			<pubDate>Tue, 29 Jan 2008 12:39:59 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Making some additional testing with other available pla ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51111</link>
			<description><![CDATA[Making some additional testing with other available players, I discovered that FLV-Scrubber (http://topfstedt.de/weblog/?page_id=208) behaves correctly and traffic-wise.

]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51111</guid>
			<pubDate>Sat, 26 Jan 2008 08:56:38 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Hi YouTube,(I misunderstood your answer, indeed you ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51066</link>
			<description><![CDATA[Hi YouTube,

(I misunderstood your answer, indeed you didn’t state YouTube and Google were using JW; sorry about that).

Now, I tried to play my videos WITHOUT the lighttpd streamscript variable, but that switches the player from http-streaming to progressive download mode, and therefore doesn’t allow me to scrub to any point of the video, but only within the downloaded range.

I also made the test playing YouTube videos in JW player as you suggested, and that confirmed me my suspicions were correct, and that indeed JW exhibits that extremely inefficient behaviour as I explained before.

]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51066</guid>
			<pubDate>Fri, 25 Jan 2008 16:42:24 -0500</pubDate>
		</item>
		<item>
			<dc:creator>YouTube</dc:creator>
			<title><![CDATA[[quote]Are you sure YouTube and Google are using JW Med ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51064</link>
			<description><![CDATA[[quote]Are you sure YouTube and Google are using JW Media Player?[/quote]No, they are using their own player. I don't see anywhere that I stated that they were using the JW Media Player.

The tests that I performed were simply using a playlist of YouTube/Google videos in the JW Media Player v3.14. The video files come directly from YouTube/Google lighttpd servers.

Meanwhile, I performed another experiment where I used:[code]s1.addVariable('streamscript', 'lighttpd');[/code] in the JW Media Player code to play the YouTube/Google videos. They exhibited the negative caching/playing behaviors that you mentioned in your first post.

So... I'm thinking, maybe you should try playing your videos from your lighttpd server [b]WITHOUT[/b] the[code]s1.addVariable('streamscript', 'lighttpd');[/code]code.

]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51064</guid>
			<pubDate>Fri, 25 Jan 2008 16:27:10 -0500</pubDate>
		</item>
		<item>
			<dc:creator>JohnDoe</dc:creator>
			<title><![CDATA[Hi YouTube,Are you sure YouTube and Google are usin ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51055</link>
			<description><![CDATA[Hi YouTube,

Are you sure YouTube and Google are using JW Media Player? 

I've tried different lighttpd configurations, and I'm quite sure it is related to the player. As I explained, I manage to reproduce youtube-like behaviour with ver 3.12 and with "pause-scrub-play" procedure, but not "only-scrub-forward" procedure. So if Youtube and Google players are based on JW, my hypothesis is that they tweaked it, as it seems to me quite easy thing to do. 
 
I'm curious: what kind of tests did you do with JW 3.14? Can you tell me where? Can I give it a try?

Thanks in advance.

(BTW, it would be useful in JW to have that colored-bar behaviour actually showing the download progress, like Google and YouTube players.)
]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51055</guid>
			<pubDate>Fri, 25 Jan 2008 15:46:50 -0500</pubDate>
		</item>
		<item>
			<dc:creator>YouTube</dc:creator>
			<title><![CDATA[YouTube and Google are using lighttpd. Look at the head ..]]></title>
			<link>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51053</link>
			<description><![CDATA[YouTube and Google are using lighttpd. Look at the headers and you will see:[code]Server: lighttpd/1.4.18[/code]

Since their videos seem to play in the JW Media Player with the same scrubbing and caching behaviors as in the Youtube/Google players (I just tested extensively with JW MP v3.14), perhaps it's something in your lighttpd configuration or maybe YouTube/Google have "tweaked" things a bit?

I'm not seeing the JW MP throw away any data, either during the download, with/without scrubbing, or after the download is complete and I then scrub throughout the timeline.]]></description>
			<guid>http://www.longtailvideo.com/support/forum/Bug-Reports/8715/Streaming-and-very-inefficient-bandwidth-usage#msg51053</guid>
			<pubDate>Fri, 25 Jan 2008 15:33:23 -0500</pubDate>
		</item>
	</channel>
</rss>