Streaming playback, the what, the why and the how
This is a quick guide in what streaming is, why it is something worth supporting and the logic needed.
What is streaming?
Streaming is when you begin playback before all content has been downloaded, assuming that the rest of the content will be ready when it is needed. Streaming normally keeps a small chunk of the content that has been downloaded, but is not needed exactly right now, but soon. A typical buffer might have a length of 5 seconds. The buffer acts as a small reserve to compensate for a sometimes uneven source of the content. Think of it as a train running on tracks while the tracks are being laid, like in the Wallice and Gromit cartoon. Preloaders, like the newgrounds tank logo is the opposite thing to streaming, they are made to load all content before playback. That is, think of it as the whole railroad track being laid before the train starts.
Why would I want to use it?
Streaming allows the user to avoid the time the content is preloading and use it to actually watch the content, saving the user from having to wait in order to consume the content. Remember, as the author, it is your job to entertain the user, not force the user to wait needlessly.
What do I need to do in order to support streaming?
Before you let the user select streaming, you must make sure that the streaming will work without any bufferunderruns, that is, when the buffer does not have the content that is due for playback when it is going to be played back. The user will not like it if there is constant bufferunderruns, since the playback is forced to stop if they do happen. There is a simple rule for knowing if streaming will work, or if it will have underruns and be a bad performance in the eyes of the user.
The rule written in plain English is very simple, if the current access speed is less than the playback speed, there will be buffer underruns. Think of it as a railroad layer that is laying railroad tracks while a train moves on the tracks. If the train runs faster than the workers can lay the tracks, the train will be forced to wait for the workers to get done.
Now, the user might not have a connection that is fast enough to stream the movie from the start, but what if we could mix preloading and streaming? Well, we can!
Thinking back to the railroad example, preloading was making the full track before starting the train, while streaming was laying the tracks just as they where needed. All that we need for streaming and preloading to be mixed is to lay some tracks before we start the train, but not all of the tracks. You will keep laying tracks while the train runs, but with a head start. This head start can compensate if you are laying the tracks slower then the train moves on them.
For your content, this is preloading until it is safe to stream the rest of the content. Now, you will ask if you can reuse the logic from above. The answer is not a lot. I will post the criteria as a mathematical inequality, that if true, the movie can be streamed from now on instead of preloaded more.
Total length of the content in seconds - Length of the loaded content in seconds > Time to download the remaining content
You should be a bit loose with this inequality and take into account that the download speed in the future may vary a bit. Now, to calculate the time to download the remaining content, you need to use a fairly odd unit, seconds per second. This unit is used for the computation of the download speed. You need to take the time used to download the downloaded content and divide it with the playback length of the content in seconds. This gives the download time per playback time. Or expressed in other words, how long time one second of content will take to download. This value can now be multiplied with the length of the content that you still need to download, to get the time it will take to download.
A trick about streaming in games
If you are making a game, or some other content that will pause playback of content for a long time, you can hope that the user will not resume playback to soon, by for example finishing the level, and only load the first chunk of content before starting playback, while loading the remaining content in the background. This will need additional loading checks after each chunk of content, to make sure the next chunk has loaded, if not you have no other option then to force the user to wait some more. But you can still repeat the chunk preloading trick and hope that the user won’t need the next chunk until it has been loaded in the background.
A little danger with the formulas
The formulas I have presented here assume that the content is not largely variating in playback length vs. download size. If you have any parts that take a lot of download size, but not a lot of playback length, compared to the rest of the content, you may be underestimating the needed download speed and prebuffering time, potentionaly causing bufferunderruns Like wise, if you have any parts that is very small in download time, but long in playback time, you will preload too much and may prevent streaming.
