Among those people fortunate enough to have a connection to the internet, many — like me — who live in the U.S. or other disadvantaged countries are forced to make do with DSL or 3G connections of 1M/sec or slower. What happens when, against the expectations of ISPs and certain large video hosting platforms, we choose to watch a video in higher resolution? If it’s hosted by Vimeo, no problem: select the HD option if provided (and if not, the resolution is still probably pretty high, depending on what the video owner uploaded), click play and then pause, and wait. Most poetry videos are less than five minutes long, so it’s not going to take forever, and in any case, if you’re accustomed to this speed, you know the drill: find something else to work on. Multi-tasking, for better or worse, is how most of us operate now anyway.
But sometime in 2013, YouTube stopped letting me do that. I’d select 360p (because anything less is unwatchable), and it would sometimes resume, sometimes not, but the buffering wouldn’t continue for more than another 30 seconds or so before stopping, no matter how long I waited. To add insult to injury, a little banner often appears below the video: “Experiencing interruptions? Find out why.” I’d click the link, and it would take me to a page telling me this was my ISP’s fault. Which was entirely unhelpful, because like most Americans, I don’t have any alternatives to the semi-monopolistic provider I already use, and they’re not about to invest in faster internet service until the government forces them to.
My preference, at least as far as videopoetry goes, would be to just stick with Vimeo, but unfortunately, many videopoets still only upload to YouTube. Today, I finally decided to do a little research and find out why YouTube sucks so hard these days.
It turns out that they’ve implemented a kind of daddy-knows-best strategy to video streaming, implementing a technique known as DASH, which stands for Dynamic Adaptive Streaming over HTTP. It sounds really good on paper.
Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH, is an adaptive bitrate streaming technique that enables high quality streaming of media content over the Internet delivered from conventional HTTP web servers. Similar to Apple’s HTTP Live Streaming (HLS) solution, MPEG-DASH works by breaking the content into a sequence of small HTTP-based file segments, each segment containing a short interval of playback time of a content that is potentially many hours in duration, such as a movie or the live broadcast of a sports event. The content is made available at a variety of different bit rates, i.e., alternative segments encoded at different bit rates covering aligned short intervals of play back time are made available. As the content is played back by an MPEG-DASH client, the client automatically selects from the alternatives the next segment to download and play back based on current network conditions. The client selects the segment with the highest bit rate possible that can be downloaded in time for play back without causing stalls or rebuffering events in the playback. Thus, an MPEG-DASH client can seamlessly adapt to changing network conditions, and provide high quality play back without stalls or rebuffering events.
MPEG-DASH is the first adaptive bit-rate HTTP-based streaming solution that is an international standard. MPEG-DASH should not be confused with a protocol — the protocol that MPEG-DASH uses is HTTP, hence the “H” in the name.
MPEG-DASH uses the previously existing HTTP web server infrastructure that is used for delivery of essentially all World Wide Web content. It allows devices such as Internet connected televisions, TV set-top boxes, desktop computers, smartphones, tablets, etc. to consume multimedia content (video, TV, radio…) delivered via the Internet, coping with variable Internet receiving conditions, thanks to its adaptive streaming technology. Standardizing an adaptive streaming solution is meant to provide confidence to the market that the solution can be adopted for universal deployment, compared to similar but more proprietary solutions such as Smooth Streaming by Microsoft, or HDS by Adobe.
What worries me about this, and the reason I’ve quoted the entire introduction to the Wikipedia article, is that it sounds like something Vimeo might eventually adopt, too. Maybe they will implement it better, though, and still provide an alternative for those who want it.
There is apparently a work-around for DASH on YouTube that might work for some — a browser add-on for Firefox, Opera, and (with some installation difficulty) Chrome — but I wasn’t able to get it working with my own Firefox installation, possibly due to a conflict with some other add-on. If you’d like to give it a try, see the instructions in PC World, “Force YouTube to buffer your entire video.”
As for that annoying “Experiencing interruptions?” banner at the bottom of YouTube videos, tech writer Christina Warren at Mashable puts it into context. Apparently, the lack of tech-savvy among many YouTube visitors may be partly to blame.
When quality fails, users are quick to blame the content source — especially if other websites seem to work just fine.
If a user experiences downtime and buffering from a service or site too many times, he or she will be less likely to use it. Content services want to be shielded from some of that blame, and pass it off to what they see as the ultimate gatekeeper: the ISP.
The real question is: Does this naming and shaming really have any impact? It would be one thing if users could pick and choose their ISP, but most of us have one choice and one choice only (the same is true for cable TV).
Indeed. The one thing Warren doesn’t point out, however, is that the message is a bit disingenuous. Yes, my service is slow, but I’m experiencing interruptions because you lot decided you knew what was best for me and stopped letting me choose to buffer an entire video.
There is one easy, low-cost way YouTube could fix things, though. Instead of an unhelpful page about ISPs, the “Experiencing interruptions?” link could go directly to Vimeo.