Hacker News Reader

Comment by taligent | Hacker News Reader

Why wouldn't they use H.264 and their existing hardware ?

Do you really think it makes more sense to decode H.264 on the device then re-encode it in another format and then decode that on the adapter ? Sounds slow, illogical and bound to introduce more artifacts.

View on HN

Nope. This is _the_ question here, what prevented them from pushing framebuffer data to the adapter, which then puts it into HDMI compatible form

You'd need 3Gbps to push uncompressed 1080p data. If you look at USB 3.0 and make a not-unreasonable bet that Lightning is slower, then you simply don't have the bandwidth to do so.

As well as bandwidth, power consumption. Chucking 3Gbps down a long wire is going to reduce battery life for a mobile product. Perhaps the controller can support it, but heat dissipation in the phone is significant?

I can't imagine that compressing and decompressing MPEG 4 uses less power, given specialised hardware for each task.

Actually, that doesn't make sense - the adapter is powered from the iPhone or iPad and still has to chuck 3 Gbps down a long wire, except now you're using the iPhone's h.264 encode hardware and an entire ARM SoC in the adapter which you have to power too.

Retina iPads already need to re-scale the image since they're higher resolution than an HDTV. Why force the little adapter to do (some pretty massive) scaling and encoding when the iPad has a very nice GPU?

It seems to me they had a system for outputting video via h.264, and they decided to use it again here. Seems like a reasonable decision at that point.

Worse case, you have two pins, one on each side like any other, that are both actually the same pin.

Reply on news.ycombinator.com