This deals with some issues I’m having with the seekbar of a player. The seekbar is the area that displays the video time as a bar that shows your current position/percentage of the video, it can also display the loaded portion of the video among other things as well. Including the video players I’ve made, most player code seems to use bytesLoded / bytesTotal to calculate the amount loaded and display in the loadbar (or whatever you call it), this load bar relates to the filesize as it reads the bytes loaded out of the total. In this same scrub bar area, I like to display the current video time in the playbar as the currentTime / totalTime, notice that this relates to the time and not the file size.
Since video is usually a variable bit rate, the loadbar (size) and the playbar (time) are not representing the same data of the video. Let’s consider an extreme example case video that consists of a first half containing live action with lots of colors and motion while the second half is a still image black and white slideshow. Understandably the first half of the video will be larger in file size than the second half, even though they each represent the same duration or half of a video… So the first half of the loadbar (size) would not correctly represent the first half of the playbar (time). So the user who watching the video load to the half point, and scrubbing to halfway through the video by clicking the load bar will see errors… The player will not be able to play the halfway (time) yet because that time is not yet loaded, even though the file is halfway loaded (size). So if we allow scrubbing through the video by clicking on the loadbar, there is a good chance that the user experience suffers because the loadbar (size) and playbar (time) are not interchangeable
Calculating display bar actionscript code:
[cc lang=”actionscript”]
//bar is display bar mc
//bar.bg.width is used as a constant to scale the percentage to the full bar width
bar.sizebar.width = (ns.bytesLoaded / ns.bytesTotal) * bar.bg.width;
bar.timebar.width = (ns.time / duration) * bar.bg.width;
[/cc]
Scrub on click actionscript code:
[cc lang=”actionscript”]
//calculate from percentage of bar width to time for seeking to
jumpSeekTo = (bar.mouseX / bar.bg.width) * duration;
ns.seek(jumpSeekTo);
[/cc]
A possible simple solution I’ve thought of is to just display a loading graphic if they click a time which has not yet loaded, but that seems counter intuitive and backwards, since the load bar would display that time as having being loaded.
I have not seen anything in documentation or anywhere online that suggests any other way to display the amount loaded which would represent the amount of TIME loaded rather than SIZE. Is there a way to know what time has loaded in the video and display that in the loadbar rather than display the percent of kb loaded?
Can anyone see something I am missing?
P.S. I already tried a couple forums to no avail: Actionscript.org forum post and gotoandlearn forum post.
Hi,
did you ever get a response to this issue?
i'm having exactly the same problem but assume it can be fixed as you-tube (which is flash video) seems to get around this.
If you did get this solved i'd greatly appreciate any direction.
regards, Rich
Hi,
did you ever get a response to this issue?
i’m having exactly the same problem but assume it can be fixed as you-tube (which is flash video) seems to get around this.
If you did get this solved i’d greatly appreciate any direction.
regards, Rich
Still nothing really. Any suggestions?
Still nothing really. Any suggestions?
there’s a way to overcome this, but it depends on the video type you play – it works for me with mp4 files. i haven’t actually tried it myself, but i think you can use this information.
when you receive the video’s meta-data (‘onMetaData’), you get an object with various parameters of the video file. in some cases (my guess is that it depends on the video’s compression type) one of the properties is called ‘seekpoints’, which is an array of objects for every seek-point in the video (again – it depends on the video’s compression), each of them with 2 properties: time – in seconds, and offset – in bytes. using the ‘totalBytes’ and ‘duration’ properties, you can run a calculation which will enable you to compare for every seek point its relative time position and size position.
this technique could have problems: for example, if there’s a 10 seconds gap between 2 seek points, and 20% difference between each seek-point bytes-loaded, you won’t be able to know what’s going on between the 2 seek-point.
anyhow – hope this will give you a head start