5 ms·

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 eith

• taligent 14y ago
  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.
  • dmishe 14y ago
    Nope. This is _the_ question here, what prevented them from pushing framebuffer data to the adapter, which then puts it into HDMI compatible form
    • jlgreco 14y ago
      Worse case, you have two pins, one on each side like any other, that are both actually the same pin.
    • seabee 14y ago
      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.
      • StringyBob 14y ago
        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?
        • morsch 14y ago
          I can't imagine that compressing and decompressing MPEG 4 uses less power, given specialised hardware for each task.
        • makomk 14y ago
          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.
    • MBCook 14y ago
      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.
• drewcrawford 14y ago
  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.
  • josephlord 14y ago
    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.
• dfox 14y ago
  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.