I'm not BoingBoomTschak who you're replying to, but he's right. My experience comes mostly from decades of reading xiph.org and ffmpeg mailing lists where such things are discussed, rather than implementing them myself. But there is constant discussion of encoder performance / quality trade-offs in software and hardware encoders. Hardware encoders, especially ones attempting to meet strict performance targets, simply cannot take advantage of some of the most complex quality improvements as they depend on information only present in past/future frames. Sometimes as many as 30 frames away.

It seems like you are interpreting this as a slight against the quality of Apple's hardware encoders, which may legitimately be very good. As are Nvidia's, Intel's and AMD's. But all of them will produce larger file sizes and lower quality than equivalently optimized non-realtime software encoders, which simply have more information and more time, memory, and flexibility to compute over it.

We're talking about fundamental properties of compression and computational time/space trade-offs. Even Apple can't design around them.

That doesn't mean Apple's hardware encoder is in any way bad or unusable. All lossy compression will be imperfect, yet much of it is useful. And most modern codecs and encoders seem to be capable of high quality results. The implications of the differences under discussion are percentages of a bitrate or tiny nearly imperceptible artifacts or breadth of available resolutions, refresh rates, and color modes or codec choice. Software encoders are always at the bleeding edge of what's possible. Hardware encoders are necessarily a snapshot frozen in silicon with limitations imposed by the implementation. The middle ground is largely already occupied by SIMD and other transform-specific ISA extensions already present in most CPUs.