4 Out of 5 Viewers Leave If a Stream Buffers Once | Hacker News Reader

4 Out of 5 Viewers Leave If a Stream Buffers Once

newteevee.com

28 pointsmjfern15 comments

It's doubly true when I'm positive it's not just my connection being slow. 20 megabits down should be plenty for youtube.

Likewise, I have plenty of bandwidth to watch Hulu - which worked fantastically when I had Verizon FiOS, but buffers with regularity on Comcast. The same Comcast who'll respond magically to any random complaint I have on Twitter, except when Hulu's involved.

I suspect that the vast majority of YouTube buffering failures are caused by Flash. Oftentimes if you fast-forward (drag the slider) past the buffering point, the movie will continue playing fine. That shouldn't even be possible if the problem was that the movie hadn't downloaded.

The problems are caused by Youtube's extremely heavy throttling and also the rules that Youtube sets on client side buffering, not Flash. Flash allows rather significant customization of buffer behavior; I've equally seen cases where Flash was used for streaming with total latency below 200ms.

At one point early on after the throttling was introduced, it was so badly done that normal videos would buffer all the time because the amount of bandwidth they allocated to the throttler was less than the bitrate of the actual videos.

I think it'd be neat if I could replace all the FLV players with a good one like the Youtube one or the Hulu one.

They often suck in that:

1) They're shitty at predicting the optimum buffer size

2) They do not continue buffering when paused, or do not indicate whether they are buffering.

3) The behavior for the connection failing in the middle of a pre-roll ad is different for the connection failing in the actual content, sometimes leaving it stuck

4) They do not always allow random access in the video, and when they do, sometimes they have to reload a portion of the video that you've already seen.

5) On some of my Macs, fullscreen viewing mode is vastly slower and more CPU intensive than just using the zoom feature in Universal Access.

1) They're shitty at predicting the optimum buffer size

This is set by the website owner, not the FLV player. For many (JW, Flowplayer, etc) it's a parameter in the HTML.

2) They do not continue buffering when paused

I haven't seen a player that doesn't continue buffering when paused. If there is one, it must really, really suck. This might also be the case with using RTMP streaming instead of progressive download, which is just plain stupid for anything that isn't live content.

4) They do not always allow random access in the video, and when they do, sometimes they have to reload a portion of the video that you've already seen.

Random access requires either using hinted FLVs (with FLVtool++) or mod_h264streaming for MP4 files, so it's not surprising that some websites don't do the necessary extra step.

5) On some of my Macs, fullscreen viewing mode is vastly slower and more CPU intensive than just using the zoom feature in Universal Access.

Flash's rendering code is notoriously bad; it does basically everything in software, in part because of the unpredictability of video drivers and so forth. AFAIK, the website owner has to set Flash's hardware acceleration mode on (it's off by default), and even then it only applies in fullscreen mode.

Interesting! Way more variables site owners have to control than I thought.

And even more than they think--Flash has a number of "hidden" variables that are either only exposed to the official media server, or are even exposed (or at least documented) only to specific major customers.

Well, this is because (at least as far as I've observed), the probability of having many many buffers is far greater for each time a buffer has already happened. Accordingly those who value their time will go elsewhere

I agree: in my experience on Youtube, most videos that buffer at all will do it many times. I don't mind the waiting so much as the constant interruption.

Sounds reasonable to me. People have high expectations for video. They've been conditioned on DVDs or traditional subscription television services. One very simple technique that would help is to fade the audio out when the buffer is empty and fade it back in to resume. If not completely then just enough to smooth out the jarring stop/start of audio. To me this is the digital version of nails on a chalk board. I can't stand it.

We need to use this to pressure giant marketers so they will pressure ISPs to improve net performance.

This may also reflect the quality of the content...

Assuming a good portion of the streams analyzed were from CDNs, this is the second time recently I've seen Limelight get a great rating from a significant study (I can't find the other one offhand).

Bad usability not only sucks in a "this sucks, but let suck it up anyway" way, bad usability sucks in a big way, like "this sucks!". It's only bad culture that lets you esteem otherwise.

Reply on news.ycombinator.com