Apple's Lightning-to-HDMI Dongle Secretly Packed With ARM, Airplay
New submitter joelville writes "After noticing artifacts and a 1600 × 900 image in the output from Apple's new Lightning Digital AV Adapter, the Panic Blog sawed it open and found an ARM chip inside. They suspect that video bypasses the cable entirely and instead uses Airplay to stream three inches to make up for the Lightning connector's shortcomings."
Can someone please explain this with a car analogy?
So I guess it may be possible to reprogram the ARM chip to maliciously invade the users computer.
Might it even be possible to turn the adapter into a minion of evil by just connecting it to your computer assuming you have the right software running?
So borrowing someones AV adapter can now be a security risk?
Doubtful. More likely that it's streaming encoded digital video via the cable itself, and the components on the connector just decode the stream.
Perhaps this is a slight step forward, as far as technology is concerned, but it's a big leap back, as far as consumers are concerned...
My sig can beat up your sig.
Was the change really worth it?
With its limited pin count, it's not a surprise that the Lightning connector does not have the bandwidth to transfer uncompressed video. But it's disappointing for it to be so bad at compression, with the MPEG artifacts shown in the article, plus latency issues with encoding/decoding. On that point, the old connector was better, and micro-USB3 would have had enough bandwidth to avoid the issue completely.
Remember when Apple was known (at least by the general public) as being the company with simple, elegant engineering?
How the mighty have fallen. Really, needing a computerized cable is just silly.
The problem is likely that Lightening likely doesn't have enough pins to just pass through HDMI like the old connector.
Silly? Maybe, but all of Apple's competitors are doing something similar because micro USB also lacks sufficient pins to pass through HDMI. (http://en.wikipedia.org/wiki/Mobile_High-Definition_Link) Except they're shoveling half the chips into the device, which increases costs on that side.
Thing is, MHL sends uncompressed 1080p over a cheap, standardized cable. Apple's standard, evidently, does not. And like you said, it's worse than the old docking cable in this regard. Regression is extra silly.
Thing is, MHL sends uncompressed 1080p over a cheap, standardized cable. Apple's standard, evidently, does not. And like you said, it's worse than the old docking cable in this regard. Regression is extra silly.
Looking at most MHL cable prices from vendors, they're cheaper than Apple's adaptor, but not cheap.
And as I mentioned, MHL drives up device prices because it requires additional circuitry in the device. Standardized cable you say? Try plugging an MHL cable into a Nexus 7. Won't work? That's because the chips required for MHL were too expensive and they were left off the Nexus 7.
Shifting half the expense to the device and half the expense to the cable isn't cheaper, it's just moving costs.
Really, needing a computerized cable is just silly.
Actually, it's a step forward and it's not the first technology to do this. The basic idea is, make the port a smart interconnect and let a smarter cable be more adaptive. That way a 4 meter cable can be tuned differently than a 2 meter cable and you can use the same port for a cheap copper cable or a long but expensive fiber cable. Regardless of how relatively expensive the cables are, replacing the computer is harder and adding new ports to mobile devices, even most laptops, simply doesn't happen. This makes a nice, future-proofed port for your laptop, phone, peripheral, etc. that will have real longevity.
With its limited pin count, it's not a surprise that the Lightning connector does not have the bandwidth to transfer uncompressed video.
Good grief. How many pins, exactly, would you say are needed for a serial connection?
Now look at the end of any USB cable and the end of a Lightning connector. What is the pin count between the two?
micro-USB3 would have had enough bandwidth
Also look at how many pins are in a USB 3 connector (HINT: ITS THE SAME).
This issue has nothing to do with bandwidth from Lightning.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Of course it has a CPU in it. Something has to do the protocol conversion.
It's not clear that Apple's AirPlay protocol, which has HTTP connections in both directions, is involved. But the pictures indicate compression artifacts. The original article doesn't go into enough detail to determine whether image compression (like JPEG) or motion compression (like MPEG) is being used. An MPEG compressor would introduce visible lag between the master and slave screens.
Whoa. Are you saying this is applying HDCP to everything it plays?
That would be very interesting, since if I made a video of my own and played it through this device, the television would be descrambling a technological measure which limits access, without my authorization. That's circumvention. This device from Apple, would cause the manufacture and sale of all HDMI compliant TVs to become illegal.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
What a waste of psilocybin....
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
I think we are missing the point a little here, They released a tiny computer for 50 bucks, now we just need a port of cyanogen for it.
When TFA says "AirPlay connection" they probably mean "AirPlay connection over Lightning". They don't have enough pins to just send an HDMI signal through the line (Lightning has 8 while HDMI has 19) so they essentially create an MPEG stream on the device, then send it to the adapter, which upscales the stream and sends it down the cable. Apparently they lack the computing power to do a realtime encode/decode for a 1080p stream, which is why you get 1600x900 at most.
Bizarrely, MHL (which also has 8 or 11 pins depending on whether your device comes from Samsung; the connector is not part of the standard) can do 1080p HDMI while having much cheaper (and probably much simpler) cables to boot. It appears that either Lightning is noticeably inferior to MHL or Apple just managed to badly screw up the adapter.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Fact: Apple has an ARM processor in the cable. It is fair to assume the video is processed by the chip in the cable.
The rest of the facts in this case are just speculation:
* Is design a 'limitation', or a design choice?
* Is the 1600x900 output seen by Panic a Panic problem or an Apple one? Is it a bug or a limitation of the hardware? File a bug and find out
* Is the connector providing Airplay over the 6cm cable? Pure speculation. Sounds plausible, even clever, but that is just a guess.
It seems to me that there is certainly an interesting story in this adapter, but I don't think we know what that story is yet.
10 seconds searching Amazon turned up an MHL cable for £3.50, extremely cheap. The Apple version is £37.
Standardized cable you say? Try plugging an MHL cable into a Nexus 7. Won't work? That's because the chips required for MHL were too expensive and they were left off the Nexus 7.
I'm not sure how that makes it non standard. Are you saying for something to be standardized every device must support it? That's crazy talk.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Wow, not only did you not read the article, you didn't even look at the pictures, did you?
Stop the presses! The are scaling 1024x768 content to 1600x900,
The cable is advertised as doing "up to 1080". It does not.
and there are MPEG artifacts happening as a result?!?! The deuce you say! There's never artifacts when you scale things! Never, I say!
Did you look at the picture? Those are not scaling artifacts: there is noise around edges. Those look like artifacts from MPEG or a similar compression algorithm. If it was just scaling, it would introduce aliasing patterns, which is not what they are talking about.
Next thing I know, you'll be claiming that Apple didn't replace all the already transcoded content on the Inktomi CDN with new, higher resolution content over night!
What does that have to do with this discussion?
It's almost already too scandalous that they used a CPU and software to avoid having to design and spin silicon for a Lightning-to-HDMI converter ASIC.
In fact, it looks like they did create an ARM-based ASIC, which on the face of it is bizarre to find in something sold as "an adapter cable". It's obviously doing something much more than or quite different from your standard adapter cable.
I can only echo some of the sentiments expressed in the bad ratings they received in several reviews from owners of Samsung Televisions which improperly negotiate EDID information by failing to negotiate on input sources which are not selected at the time the device comes online. One would almost think this might be an issue for Linux systems when trying to use HDMI to output to Samsung equipment, or that Dish Network DVRs might have similar problems (with the fix being to plug the device into the input channel which is selected by default when the television is powered on).
EDID? Linux? What? The article doesn't mention those topics at all. It's talking about an ARM-based chip that was unexpectedly found in a new model of a supposed "adapter cable" from Apple that is providing results that are substantially inferior to what was available on older models of Apple's similar products. As a result, if you use this cable to attach your iWhatever to a TV, you get laggy, downsampled, artifact-laden video, where Apples previous products and products from their competitors deliver sharp, un-transcoded 1080p video.
Consider this hypothetical: Movie studios license their works to cable and satellite networks. The studios and networks want to measure to what extent HDMI playback from iDevices competes with cable and satellite TV. (In this case, playback on the internal display of a mobile device is considered complement, not competition.) So they get Apple to add something buried in the protocol between the iDevice and the adapter to measure this. The ARM microcontroller in the adapter measures the screen size of the device on the other end of the HDMI cable and reports it to the iDevice, which sends it to Apple the next time the device connects to iCloud.
You're being extremelly disingenuous:
1- MHL is cheap, there are plenty of $2 MHL cables. If you like paying for brands and stickers, that's your choice... they have nice ones with golden connectors and one-way flux optmizations, I'm told.
1b- MHL is cheap, the cost to implement it is nowhere near whatever Apple are doing with their fake video cable.
2- MHL is a standard. The fact that some chose not to have the feature does not change that. A bit like.. you know... you're PC not being an FM radio does not make FM radios un-standard...
3- are you trying to imply that MHL is as expensive as having a failed proprietary interface + **active** components to fake a high-def video link, but that just the cost are split differently ? I can assure you that Apple's "solution" is several times more expensive both to implement in the device, and for the cable. And wayyyyy worse in terms of quality.
The Cloud - because you don't care if your apps and data are up in the air.
Sending video through Airplay is WAY easier than keeping cables around to hook up an iPad to a display
As opposed to keeping cables around to hook up a $99 AirPlay receiver to a display?
and having to know how to switch video inputs (still an unfathomable mystery to many)
If it's unfathomable to switch inputs to the iPad, it's just as unfathomable to switch inputs to the Apple TV.
I've fallen and am only outselling everyone else in the market by a huge margin!
Do you want me to go dig up the story about Nexus tablets outselling the iPad? I will if you want.
If Apple are having the compress the high-rez signal to get it out or over the cable, then it's a step backward.
Agreed. I did not mean to imply this was a good technology (either the port or the adaptor), just that conceptually putting a chip in the cable seems like an excellent idea.
The electronics involved have nothing to do with AirPlay, and this is not "news" in any way. Sorry to ruin excitement and conspiracy theories... :-)
I am willing to bet serious money that all these chips do is decode whatever proprietary protocol Apple uses for transmitting video over the Lightning port to a standard HDCP protected HDMI signal. This is needed because the Lightning port has no other way of transmitting the video - and this has been clear from the day Apple revealed the Lightning port to the world. It is really just a high-speed 8-pin serial connector. Nothing else.
In addition the chips probably try to introduce a classic vendor lock-in factor, making it hard for 3rd party vendors to provide similar cables and accessories for the Lightning port without paying royalties to Apple (read: legal tech-extortion).
Also, the scaling-problems mentioned are without a doubt due to the screen-mirror scheme involved. If they streamed an actual 1080p video file directly, the result would likely be very different.
The speculation in the article is so far from reality it almost hurts... They get points for taking it apart and all, but they could have reached the correct conclusion merely by reading up on the existing specs of the Lightning port (if they had bothered to add a bit of digital-video knowledge from Wikipedia that is).
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
does it run linux?
...except my Apple ethernet cable needed a firmware update.
Airplay is not involved in the operation of this adapter.
It is true that the kernel the adapter SoC boots is based off of XNU, but that's where the similarities between iOS and the adapter firmware end. The firmware environment doesn't even run launchd. There's no shell in the image, there's no utilities (analogous to what we used to call the "BSD Subsystem" in Mac OS X). It boots straight into a daemon designed to accept incoming data from the host device, decode that data stream, and output it through the A/V connectors. There's a set of kernel modules that handle the low level data transfer and HDMI output, but that's about it. I wish I could offer more details then this but I'm posting as AC for a damned good reason.
The reason why this adapter exists is because Lightning is simply not capable of streaming a "raw" HDMI signal across the cable. Lightning is a serial bus. There is no clever wire multiplexing involved. Contrary to the opinions presented in this thread, we didn't do this to screw the customer. We did this to specifically shift the complexity of the "adapter" bit into the adapter itself, leaving the host hardware free of any concerns in regards to what was hanging off the other end of the Lightning cable. If you wanted to produce a Lightning adapter that offered something like a GPIB port (don't laugh, I know some guys doing exactly this) on the other end, then the only support you need to implement on the iDevice is in software- not hardware. The GPIB adapter contains all the relevant Lightning -> GPIB circuitry.
It's vastly the same thing with the HDMI adapter. Lightning doesn't have anything to do with HDMI at all. Again, it's just a high speed serial interface. Airplay uses a bunch of hardware h264 encoding technology that we've already got access to, so what happens here is that we use the same hardware to encode an output stream on the fly and fire it down the Lightning cable straight into the ARM SoC the guys at Panic discovered. Airplay itself (the network protocol) is NOT involved in this process. The encoded data is transferred as packetized data across the Lightning bus, where it is decoded by the ARM SoC and pushed out over HDMI.
This system essentially allows us to output to any device on the planet, irregardless of the endpoint bus (HDMI, DisplayPort, and any future inventions) by simply producing the relevant adapter that plugs into the Lightning port. Since the iOS device doesn't care about the hardware hanging off the other end, you don't need a new iPad or iPhone when a new A/V connector hits the market.
Certain people are aware that the quality could be better and others are working on it. For the time being, the quality was deemed to be suitably acceptable. Given the dynamic nature of the system (and the fact that the firmware is stored in RAM rather then ROM), updates **will** be made available as a part of future iOS updates. When this will happen I can't say for anonymous reasons, but these concerns haven't gone unnoticed.
"Based on a [December] survey of 2,400 consumer electronics stores in Japan, Google's Nexus 7 tablet had 44.4 percent of the market versus the iPad's 40.1 percent, according to Nikkei, Japan's largest business daily."[1]
[1] Brooke Crothers. "Google Nexus 7 tops iPad in Japan: Is this a trend?" CNET, January 16, 2013.
So how did I fail?
Err, never? Simple, elegant design maybe, but engineering?
Apple-style design requires a LOT of engineering.
The first Macintosh, for example, has a fully modern GUI in 128kb of RAM. That's kb. Very few engineers today could get anything useful to run in an eighth of a meg, and even fewer could include an entire OS, a GUI, AND still have room for an application. They made some pretty major compromises to get it done, but they did it.
More recently physical design has been more important for them. But that takes engineering, too. The Macbook Air doesn't look like it's been heavily engineered, but do you seriously think that a bunch of Art Majors figured out how to mass-produce a fully functional laptop that fits in a damn envelope with no engineering help?
I'm not saying Apple should be known as an engineering company. It's not a company that lives and dies by technical specs. But Apple's designs just don't work without some damn good engineers. Their work is very hard to see, largely because Apple wants their products to look seamless, but that doesn't mean their work never happened.