>>34
Hardware decoders are usually fairly inflexible things(if there's a bug, you're stuck with it), unless you're talking about a FPGA, but then the per unit cost would be much higher. This means that if there's a bug, you can't fix it unlike software which is upgradable. The best solution isn't H.264 decoding chips, instead, you just write hardware decoders only for simple, easily testable parts of the decoding process which would be CPU intensive otherwise (things like (I)DCT transforms, certain filters, CABAC decoding and so on), then you write your decoder in software, but have it offload all the intensive parts to the hardware, thus you achieve both upgradability and low CPU usage. This also has the advantage of being able to use the hardware parts to decode not only one format, you could could use it to decode MPEG2/VC1 and other things beside H.264, as long as they're based on the same base concepts (of course, this can't be applied to more experimental non-DCT based codecs, such as wavelet-based ones, but currently wavelet-based codecs are inferior to DCT based ones, simply because people aren't giving them nearly as much attention/development time and the CPU requirements can put high-end desktop CPUs to shame.