Hi,
I think I found another bug or extremely inefficient behaviour of the player.
Here's the scenario:
I'm using lighttpd http-streaming for flv videos.
1. I start streaming a video.
2. I wait until it gets downloaded. (the playback data-rate is lower than my bandwidth, so the download is always ahead of the playback, and it goes until the video is fully downloaded).
3. I press Pause.
4. Being paused, I can scrub freely from position to position, and no further downloads (http requests) are sent to server. Everything works as expected.
5a. With the ver. 3.14 of the player, I pick one point in the video while still paused and then press "Play", and here the player sends another http request and starts downloading again (from that point on and again until the end of the file). This is bad.
5b. I made a little test also with the ver. 3.12: still *while paused*, and under the same conditions (from point 1. to 4.), pressing play again DOESN'T send another http request, so apparently ver 3.12 behaves more intelligently than 3.14: it has downloaded the video and it doesn’t need to request it again.
5c. Now, holding the same scenario from points 1. to 4., but instead of pressing pause and then scrubbing, I simply try to scrub without pause, and I noticed that it always sends an http request (both ver. 3.12 and ver 3.14).
This behaviour is extremely bandwidth inefficient: the player carries on downloading until the end of the file, but whenever you need to jump to another position (even very near one), it simply THROWS AWAY all the downloaded parts and starts downloading it again f(from that point on).
As explained before, on this regard the ver. 3.14 is even worse than 3.12, since 3.12 at least reuses the downloaded parts IF YOU FORST PAUSE IT and then jump forward, while 3.14 makes http request for every press of play or scrub, whatsoever.
In general, in this context there are two strategies for rational bandwidth usage:
A. one is to put to sleep the downloading process as soon as some kind of buffer is full (this can also be done server side, and some PHP-streaming scripts do it, look for example Xmoov’s PHP: http://xmoov.com/xmoov-php/source/ (see bandwidth limiting code chunk and the usage of usleep() function). By the way, Lighttpd’s mod_flv_streaming doesn’t behave that intelligently, and could in the future have a configuration option for that kind of behaviour; but that’s another story.
B. The secont possible strategy is to carry on downloading (until the end), but then reuse the downloaded parts for scrubbing, without the need for further download as long as the required position is within the downloaded range. This is ho YouTube does it (try to jump to a position and look at the red bar).
None of this seems to be the case with the behaviour of JW FLV Media Player.
Theoretically, it seems to me that there could be a very simple fix: just pick the current 3.12 behaviour, and when an user scrubs *during* playback you internally first pause it, then jump to the position, and then start the playback again.
Cheers.
P.S. By the way, this is not the only case of 3.12 behaving better than 3.14: you can have a look at this one: http://www.jeroenwijering.com/?thread=8629
This is the exact same behavior as all RTMP streaming from servers such as FMS and Red5.
Viewing a 5MB video can easily create total traffic of 10-15MB per view if the user scrubs much.
(As an aside, you are talking about traffic, NOT bandwidth.)
This is why I don't recommend using RTMP streaming.
Yet there are many video sites using RTMP streaming for millions of users.
Go figure...