Hours of Video Delivery Per GB

The higher the resolution, the more GB used indeed. If you jump fullscreen, higher quality content is loaded.

Also, do you know if your player uses adaptive streaming or a single video? In the latter case, the video is progressively downloaded, resulting in bytes delivered that were not watched.

Last, we do not track HTML5 time viewed yet. If you have lots of iPad/iPhone users, they may skew your stats. We are working on including their usage in the "time viewed" stats, which will be fixed early Q4.

About 15% of my viewers are using iPad/iPhone, so that would account for some, but only a small part of the issue.

Where in my account can I look to see if I am using "adaptive streaming" or "single video"?

Also, I am only showing two videos at the moment, and they are both 4 minutes long. It someone watches only 1 minute and they have a good connection, would all 4 minutes load during the time it takes the viewer to watch the first minute? If so, when the viewer stops the video after watching one minute, would I be charged for the loading of all four minutes of video even though only one minute was actually watched?

Thanks.

Steve

Whether you're using adaptive streaming or not is a setting of your player templates. If you look into the details of the player(s) you use for embedding, you'll see adaptive streaming option.

With your example, you would indeed be charged the full 4 minutes in case of a single video. In case of adaptive streaming, you'd only be charged for the 1 minute. This b/c adaptive streaming only sends the bytes "just in time" and a single video is simply a progressive download, loading as fast as your connection is.

You can also give me the login name or key of your account, then I can see what settings are used.

My login name is srs898 "AT" Yahoo.com (sorry, just an attempt to keep my email address from the spam-bot email address harvesters)

I checked your account, and all streaming options are perfectly set. If I look at your first video, I see it is 4 minutes long and 22 MB. This means you should be able to do about 3.3 hours of streaming per GB (22/4*60 = 330MB/hour). This means that you have spent only about 1.3GB on streaming (4.3 hours / 3.3 GB/hour). So 1.3 GB is missing.

Next, I went to the analytics page and downloaded the CSV export. This export breaks down the views in streams (in flash) and downloads (by html5 devices). There was a total of 91 downloads, which can very well lead to the 1.3GB that is missing. After all, if all "download" users would grab the entire video, you'd look at an additional 2GB of traffic. Some of the html5 viewers leave the page early though, so 1.3GB sounds very plausible.

After some additional testing, it seems that the iPhone/iPad loads the video on page load, and not when a use clicks play. That's why the 91 downloads is such a large percentage of your overall 203 streams.

I have been suspecting such thing could happen, but ignored it so far b/c iOS traffic used to be so small (<1%). Now it's getting traction though, this is really becoming a problem. We will immediately do some work on this to make sure that in HTML5, videos only get loaded when the user clicks "play" and not before.

Thanks, Jeroen.

I'm impressed by the depth and clarity of your response.

Thank you for looking in to this.

Steve

Seems this post was about 6 months ago and I am wondering if there was a resolution for html5 devices. I too am "missing" some GB.

Thanks,
Sam

We have one option fixed for HTML5 devices: they don't load load videos on page load anymore. We did this by adding the "preload=none" attribute to our video tag fallback.

Part of the credit for that goes to Apple, since they fixed an issue in pre-loading of videos on iOS5. You can see iOS4 load parts of files and iOS 5 not in this test setup:

http://www.longtailvideo.com/html5/preload

The second part, HTML5 videos getting downloaded instead of streamed, is not something we have tackled yet. We are investigating offering Apple HTTP Live Streaming support, which will fix this issue for iOS and Android 4 devices. We will likely roll this option out end of Q2, around the same time Android 4 devices should get some traction:

http://developer.android.com/resources/dashboard/platform-versions.html