adaptive preloader forumla

[hp3]

Hopefully some of you folks can verify if I firgured this forumla out correctly.

First An adaptive preloader, if you are not already familiar with it, is a way of loading x% of a sound or video, before starting playback. The amount to load depends upon the user's bandwidth. Developers use it most commonly for situations where the user's bandwidth is less than the stream's bandwidth. So in effect you require the user to load a large percentage of the media (not 100%), then as the media plays, the remaining percent loads. This is a faster delivery method than loading the media completely before playback.

An analogy might be, giving a slower car a head start in a race. You need to determine how much of a head start (buffer size), to give your car (download bit rate), to beat the faster car, (stream bit rate) to the finish line (end of stream).

(1 – Download bit rate / Stream bit rate) * duration of sound in seconds

For example, in order for a user with download bit rate of 48kbps to successfully support a 56kbps audio stream (without interruption) of a 60 second audio sample, the buffer size would be:

(1 – 48/56) * 60 = 8.4 seconds of audio to buffer

set _soundbuftime property to 8 or 9.

I know how to get user bandwidth, but I want to make sure I am calculating the _soundbuftime correctly. Any help much appreciated.

[jonmack]

I concur

start play time (sec) = (1 – Download bit rate / Stream bit rate) * sound duration sec)

But, in your numerical example, you had 48/56, which isn't the formula? Did you mean 56/48?

I'm sure you'll apreciate that this is a best possible conditions model, and that it normally doesnt go 56k etc etc. I would round up seconds and possibly add a few to cut out a bit of stop/starting

P.S. Lovely analogy

[hp3]

thanks for the post.

I did mean 48/56. 48kbps being the user's bandwidth and 56kbps being the media's encoded bitrate. So in my formula I consider "Download bandwidth" to be the user's connection speed, 46kbps and "Stream Bandwidth" to bethe media's encoded bitrate, 56kbps.

This was just an arbitrary example, and as you suggest, it would be a good idea to add in some insurance for changes in user bandwidth during stream.

I guess my logic for this forumla is to determine, as a percent, how much larger the media's encoded bitrate is compared to the user's download bitrate. If I were to remove this excess data from the media file then the bitrate of the media file and the user's stream would be the same, allowing for theoretically smooth streaming. Of course by "removing excess data" I really mean load it first then rely upon play during download for the remaining data.

So assuming that the user's bandwidth is always smaller in this situation, I would divide the user's bandwidth by the media encoded bitrate to get a percentage. That is why I divide 48/56.

[Noflashdancing]

The formula should be approximated as follows...

wt = dl - cd + cd*.1

where:

wt = wait time
dl = total download time
cd = clip duration

This is the formula that Macromedia recommends (as an approximation) for streaming video (ie for SWF or FLV digital video encoded with Sorenson Squeeze using the proprietary Sparc codec). However, in theory, the formula also holds true for audio only.

Here is an example for a video clip (again, the same should hold true for audio):

SWF bytes = 416KB = 416000 B

Therefore, dl = (416000 B)/(4700 KB/s) = 88.5s

Where 4700 KB/s is the rate Macromedia uses to approximate the bandwidth for a 56K modem user.

For this example, my Sparc encoded movie is 83 s long, therefore cd = 83 s.

Lastly, we add 10% of the clip duration for a total wait time of:

wt = 88.5 s - 83 s + 8.3 s = 13.8 s

Hope this is useful

[hp3]

thanks for this information, I'll try it out.

[Noflashdancing]

Hi hp3,

I just finished coding a customized SWF/FLV player, and ran into the same issue that you brought to our attention in this thread. The player streams a variety of custom SWF/FLV "modules"--all of which are encoded differently depending upon how I set up the Sparc codec using Sorenson Squeeze. Hence, I require a "robust" solution. I found the formula while reviewing a Macromedia document explaining video optimization.

Last night, I tested the formula on a short clip (actually the one mentioned in my previous post) to see if it worked. Note: using a bandwidth approximation of 4.7KB/s seems to be a bit aggressive--at least in my case and through my ISP. Therefore, I lowered the approximation value to 4.3 KB/s. This is based upon my own "download observances".

My original FLV clip was encoded using 2-pass VBR. I imported this clip into Flash and placed it on the stage running at 12fps (note that the real frame rate is actually determined by the FLV clip). Nevertheless, I used 12fps for my final SWF calculations.


Using the formula:

At 12fps, and assuming 4.3KB/s, my SWF needs to load about 241 frames before "all systems are go"...

(436 KB)/4.3 KB/s) = 101.4 s
(996 f)/(12 fps) = 83 s

using the approximation: wt = dl - cd + .1cd

wt = 101.4 s - 83 s + 8.3 s = 26.7 s

(note using 4.7 KB/s yields 20.1 s)

I use this information to set the buffer time:

mySWF._setbuftime = 26.7;

Note: though the Flash documentation is rather lacking, I believe this value actually indicates 26.7 s of "actual SWF playback" as opposed to a "real" wait time of 26.7 s.

It worked perfectly. If I use 20.1 s, the stream hangs near the end (at about 80%). The trick to streaming SWF for 56K modem users (or for that matter any bandwidth) is never to "push the envelope". Always use conservative estimates to ensure smooth playback--there is nothing more anoying than interrupted video/audio. I would rather sacrifice some quality or wait a few seconds longer (in this case 6.6 s) if the tradeoff equals smooth playback

Please post your testing results hp3, I'm interested in a second opinion

Rob

[hp3]

Yes _soundbuftime is a quantity of media not a duration, which is not very clearly explained in the docs.

Unfortunately, I probably wont have time for awhile to get back to my adaptive load code project. I will let you know when I resume and probably post in the FlashMX video forum at that point.

thanks again for your notes.

[03ricr]

aren't you guys forgetting that there are 1024 bytes in 1 kb?!!

[Noflashdancing]

03, bytes (as a unit of measurement) aren't used in my calculations. I use KB consistently. The equation simply yields the number of seconds based upon file size (KB) divided by baud rate (KB/s)...

(KB)/(KB/s)=(s)

There is no need to take bytes into account here... not sure what you are driving at 03???

[hp3]

---
aren't you guys...
----

none of my posts in this thread even deal with KB, my values where all kbps (kilo bit per second).

[hp3]

Noflashdancing,

mySWF._setbuftime = 26.7;

I'm not familiar with _setbuftime, unless that is new with MX04. Is this the same feature as _soundbuftime?

[Noflashdancing]

HP3,

This thread goes back a ways...

I haven't looked at any of this in several weeks. I believe I made a typo, and you are correct--sorry about that.

I also now see what 03 was getting at... and may be right. If the baud rate is in Kbps then you should convert bytes to bits.

Sorry, I don't have time to mess with this now... just be advised that there may be a small conversion problem associated with my (actually Macromedia's) formula. Though it can be easily compensated for.

[hp3]

ok then, I was going to point out one other idiosyncracy of _soundbuftime, and that is that flash always "floors" decimal values in _soundbuftime.

for example

_soundbuftime = 26.9
trace(_soundbuftime)
// flash returns 26

so for insurance, an adaptive preloader should "ceiling" decimal values so that you dont end up "short changed" for buffer size.

_soundbuftime = Math.ceil(26.9);
trace(_soundbuftime)
// flash returns 27

[hp3]

If anyone is curious, I wrote an article about this approach to adaptive buffering.

http://www.sonify.org/home/feature/r...daptivebuffer/