

Why AirPlay just wrecked your responsive media strategy - micheljansen
http://cvil.ly/2012/02/20/why-airplay-just-wrecked-your-responsive-media-strategy/#comment-996

======
mwexler
This probably matters more when more people use Airplay and devices like it to
bounce from mobile to bigscreen. As of now, solving for that edge case seems
like a waste of time vs. the far more general case of folks watching video
requested by a mobile device on said device.

To be fair, one survey in Dec '11 estimates that Apple will have 32% of the
tv-box market
([http://www.mediapost.com/publications/article/164141/apple-t...](http://www.mediapost.com/publications/article/164141/apple-
tv-to-capture-32-share-of-connected-tv-play.html)) so it may be more common
than I suspect...

As a compromise, I wish Netflix and others would just let me as a user choose
whether I want a high stream or a low stream and not worry about all that
"detection" stuff. This allows me to control my bandwidth usage to better
reflect the conditions I'm in (paying per byte vs. my home network, etc.).
Then work on making all this auto-adjustment stuff while always giving the
user the option to ratchet it up (and suffer drops) or ratchet it down (and
lose resolution), as they see fit.

(Related, a bit, to WSJ article
([http://online.wsj.com/article/SB1000142405270230381290457729...](http://online.wsj.com/article/SB10001424052702303812904577293882009811556.html))
about new iPad users blowing through their bandwidth due to excessive use of
higher def video)

~~~
shad0wfax
Just on that point of Netflix, they do let you set the streaming quality on
your account settings. This affects the streaming to all devices though and is
a master setting.

But I agree with you, we can be the best judge of the quality we want, rather
than the auto-detection. The adaptive streaming (even Apple's http live
streaming supports this) is a possible solution for auto detecting the best
bandwidth to use, though it is a lot of work for content creators.

------
themgt
This is a tiny microcosm of an emerging reality - an increasing independence
between input/output devices (and accompanying UI) and the physical computing
hardware that powers it all - i.e. once your smartphone is powerful enough to
run all your apps, it will

Software will need to get better about detecting what sort of interaction and
output formats a user wants, because it won't be able to be assumed (even
basic stuff like touch vs. k&m) by the platform

------
modeless
Apple better not provide a way to detect AirPlay, because the first thing
media companies will want to do is block it. They're still laboring under the
outdated idea that TVs are separate from every other kind of display.

~~~
ConstantineXVI
I believe it's already blockable, noticed Netflix won't let you play via
AirPlay.

~~~
jonny_eh
They "block" it by reimplementing the entire videoplayer UI. This is
unfortunate because it's inferior to the system provided videoplayer UI, and
not just due to lack of AirPlay support.

Notice how touching the screen causes the UI to appear immediately, instead of
the delay you'd normally expect. Also, the seek bar is much more sensitive and
difficult to use.

I've been wondering why they went through the trouble of trying to make a
nearly identical video player UI, but I suppose blocking AirPlay seems like a
good explanation.

~~~
owenfi
That might be the way they block it, but it must not be the only reason for
customizing their UI.

For movie playback there is a simple allowsAirplay property, and for mirroring
they could draw an empty view (or whatever) across the 2nd screen.

------
josscrowcroft
Seems to link to a comment ID fragment on the page which jumps it to the
bottom. Better edit the link!

Good read too.

~~~
micheljansen
Oops, well-noticed. I didn't notice that was there when I copy/pasted the
link. Unfortunately, HN does not allow me to edit my URL. Can someone with
superpowers please fix this?

------
rizwan
Yeah, the issue seems to be that, when an iPhone loads the page containing the
video, PBS does some user agent checking to determine what video source to
provide.

When iPhone goes to AirPlay, it provides the AppleTV with the only stream
source it received.

Ideally, either the HTML5 video tag could define multiple streams based on
size (similar to how it can provide different streams based on video format),
but since that's not in the spec, I suppose we have to conjure up a
"standardized" convention.

~~~
adamjernst
This shouldn't be done at the HTML5 level, but at the codec level.

HTTP Live Streaming already provides a perfectly serviceable way to do exactly
this: provide multiple streams at different bitrates and let the media library
choose which is best for the network and output resolution.

This is probably one reason why Apple has been using its muscle to force _all_
iOS apps to use HTTP Live Streaming. They knew about exactly this problem:
iPhone app developers assuming you would never play the video on a large
screen, but with AirPlay you will do exactly that.

~~~
mikeryan
_HTTP Live Streaming already provides a perfectly serviceable way to do
exactly this: provide multiple streams at different bitrates and let the media
library choose which is best for the network and output resolution._

HLS doesn't solve this problem. HLS adjust bitrates, the problem here is
resolution switching (which sometimes is involved in bitrate switching). On an
iPhone the largest HD resolution you can fit on the screen is 960x540. On an
iPad or OTT device (Roku, AppleTV) its 1920x1080.

Slight niggle, this shouldn't be addressed at the codec level but at the
container/wrapper level.

------
moskie
This also illustrates one of my bigger gripes with how AirPlay works, in
general. Why should the mobile device, that has limited battery (and maybe
connection speeds) be the device that does the heavy lifting in this
situation?

The Apple TV is constantly plugged in to a power source and (presumably) has a
more reliable data connection, and will always be within range of the display.
Make it do all the work. Seems very fragile the way it is now.

~~~
bradleyland
Because the problem solved by the Apple TV involves a branch in the process.

1) User is using their mobile device (happily) to locate content that may come
from a wide variety of sources

2) User locates content that they'd like to share on a larger screen

3) User "hands off" (this is the branch) the playback of the content to the
Apple TV

Many complex interactions might have occurred in steps 1 and 2. These
interactions, typically, don't translate well to television screens. Based on
adoption rates, no one wants to use a keyboard in their living room, and the
content users want is already accessible on their mobile device. App
developers welcome the opportunity to _not_ develop for yet another
device/platform.

So, you have two choices:

A) Let the mobile device do the heavy lifting and stream only "dumb" video to
the Apple TV...

or

B) Devise some schema for handing off the entire session necessary for the
Apple TV to connect (and authenticate, authorize, etc) to the media source.

Option B is full of pitfalls and difficult problems. Many are already solved,
but they're just not there yet, IMO. I think we'll get there eventually
though. As more and more services use the "Sign in using X" (where X is
Facebook, Twitter, Github, etc) model, more and more users will become
accustomed to federated login solutions. That is, ultimately, what would be
required to hand off the direct connection to the media source.

~~~
moskie
Good points. I guess I just fall into the category of people who want my
phone/tablet to act as a fancy remote control, more than I want to be able to
transition from watching a specific thing between multiple places.

------
cleverjake
As shown with responsive web design, it is increasingly becoming an antiquated
idea that a small screen means small/underpowered device.

~~~
mikeryan
_antiquated idea that a small screen means small/underpowered device._

That's not what is happening here. They're not assuming a small screen is
under powered, they're assuming _a small screen is a small screen_. Why would
they deliver 1920x1080 or 1280x720 resolution video to a device that only has
a screen resolution of 960x540?

~~~
cleverjake
Why would they deliver 1920x1080 or 1280x720 resolution video to a device that
only has a screen resolution of 960x540

because it is no longer always true. that was the point of the article.

------
devindotcom
A channel-specific app on a phone beaming it to a set top box, which sends it
to the display? No thanks, says a huge majority of consumers.

An all-in-on smart TV with content provider agnostic search and play on demand
takes this convoluted media pathway to school.

~~~
zevyoura
The difference is one of those exists, and the other doesn't.

------
starfox
First of all, here is Downton Abbey Season 2 on Amazon [
[http://www.amazon.com/Downton-Abbey-A-House-
History/dp/B006M...](http://www.amazon.com/Downton-Abbey-A-House-
History/dp/B006MW3VGA/ref=sr_1_1?ie=UTF8&qid=1332348783&sr=8-1) ]

I'd like to know the actual stream bitrate he experienced. It's pretty hard
for me to empathize without that number.

