Hacker News Reader

Comment by dmishe | Hacker News Reader

Yep, and the comment about them using already existent h264 support in hardware I think supports dry-run-fastest-to-deadline solution.

Re pins, I'm not EE either, but I don't get why people concern about number of pins so much, as I asked earlier in this thread, is there a relation between number of pins and bandwidth (well with physics involved there is _some_)?

View on HN

Still not an EE, but as I understand it, if you are creating your own controllers and you also control how the cable is shielded, pin count doesn't matter much except for power.

Traditionally it's been easier for most hardware makers to double the pin counts than to build controllers that run at twice the clock rate and also make everybody use fancy cables. But traditionally not everybody has PA Semi across the hall to build chips for you and years of experience selling $50 cables to consumers via direct retail. So I'm betting that the usual economics of the consumer data interface market don't apply to Apple.

Has this been true since the late 80's/ early 90's when serial ports left parallel ports behind?

With serial techniques such as differential encoding parallel transmission off circuit board has been obsolete for a long time. The potential skew between the pins is too great and synchronisation too complex.

There is pretty significant relation between number of pins and prices of almost every piece of hardware involved. IC package price is almost linearly dependent on number of it's pins and for most mass-manufactured chips packaging is major component of final price. Also wide parallel interfaces are harder to design from interference perspective and to route on PCBs. General shift to essentially serial interfaces for almost everything except main memory is motivated by simple fact that trading silicon area used by serialization/deserialization logic for less device pins, simpler boards and simpler system design is very worthwhile whenever it's at least partially possible. For very slow interfaces it has been this way for at least 30 years, since mid 90's for slow system buses (that's why around 2000 motherboards stopped having ISA slots, ISA was replaced by serial LPC interface around that time) and since early 00's for almost everything in non-specialist applications.

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.

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