And HDMI does it effortlessly. That's exactly what these interfaces were designed to do: raw massive data with low latency over short distances, suitable for processing in dedicated circuits, not SOCs.
> suitable for processing in dedicated circuits, not SOCs.
Your splitting hairs. Pretty much all HDMI transmitter ICs have a microcontroller on board, they need a processor to deal with the protocol configuration, DDC and HDCP. Probably most are using some 8051 design plunked into the chip. They are SoCs by any reasonable definition.
Yes, of course. But they have the the actual transfer of the raw data offloaded onto specific circuitry that mostly just passes it through, something the processor part of a SOC would be terrible at. That's not what Apple is doing; they take in a normal lossy compressed video stream (H.264, who knows) and then reconstruct a HDMI signal.
The only difference between what you've described and what is going on in this adaptor is the inclusion of h264 decoding. The use of this is an argument that can be had (personally I think it was a great play on Apple's part, see my comment here: http://news.ycombinator.com/item?id=5308345)
The rest of this is ancillary stuff. They aren't decoding h.264 on an ARM core, that's impossible for any significant bit rate, they are doing it with a purpose built bit of hardware, just as the HDMI encoding is done in a purpose built bit of hardware. Incidentally the encoding of HDMI is a mess, the spec is worth a read some time.
But then there's 4K, if we're talking about future proofing.
Well, say right now it cannot transmit 1080p60 raw. Could it with new hardware in device and adapter?
Or put another way — does number of pins limit bandwidth in any way?
> Well, say right now it cannot transmit 1080p60 raw. Could it with new hardware in device and adapter? Or put another way — does number of pins limit bandwidth in any way?
Based on what has come out about lightning it appears to have 2 differential data channels (same as USB2). There will be some upper limit on frequency but its impossible to know without detailed specs. Its also not clear if one is locked as send and one as receive, or if they are configurable, there is an ancillary control channel so anything seems possible.
For comparison, HDMI has 3 data channels, each with raw bit rate of up to 3.4Gbit/sec (~2.7Gbit/sec data).
Unencoded video is about the most bandwidth intensive thing I can imagine coming out of or going into a phone, and will remain so for a long time.
1080p30 @ 24bit is roughly 1.5 Gbit/sec before you talk about transport level ecoding (8b/10b) or audio.