Why AirPlay just wrecked your responsive media strategy | Hacker News Reader

Why AirPlay just wrecked your responsive media strategy

cvil.ly

31 pointsmicheljansen27 comments

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...) 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...) about new iPad users blowing through their bandwidth due to excessive use of higher def video)

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.

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

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.

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

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.

I think a better explanation would be that they used the same video decoding for all devices and tried to implement a UI for that rather than re-encoding their entire library.

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.

Apple engineers specifically recommend against reimplementing the movie player UI as well.

Not if you mirror your display.. they take advantage of the external display when you mirror

Apple already does and the media companies already do.

At least, when it comes to AirPlay Mirroring:

https://developer.apple.com/library/safari/#documentation/Au...

Basically, you can subscribe to a notification when a second screen is connected and display there whatever you want. The French TV channels M6 and Canal+ have blocked it for a few months now. (which is absolutely stupid obviously)

As far as AirPlay from inside the default media player object, I'm not sure if it's notified to the app and I don't have an iPhone 4S or iPad2+ to check.

edit: the paragraphe "Provide Audio Metadata" from the link above seems to say that the app also knows when it's "plain" AirPlay.

> Apple better not provide a way to detect AirPlay, because the first thing media companies will want to do is block it.

They do provide a way, of course, and developers are free to disable it, and some do. On my iPad I have apps for RTE (Irish state broadcaster), TV3 (Irish private broadcaster), BBC (UK state broadcaster) and Channel 4 (UK pseudo-private broadcaster). RTE and BBC allow you to use AirPlay, TV3 and Channel 4 do not, and Channel 4 specifically mentions the fact that they don't in their FAQ, and imply that they never will.

Far weirder, the NetFlix app doesn't do AirPlay, even though they provide an AppleTV app.

Lovefilm already block AirPlay for their streaming app (I'm not sure if screen mirroring helps) On the iPad 1, the AirPlay icon shows up, but selecting the AppleTV as the output only plays the audio. Video stays on the iPad.

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

Good read too.

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?

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.

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.

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.

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.

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...

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.

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.

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

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?

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.

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.

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

First of all, here is Downton Abbey Season 2 on Amazon [ http://www.amazon.com/Downton-Abbey-A-House-History/dp/B006M... ]

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

Reply on news.ycombinator.com