4 ms·

> So basically, video encoding is bad show for Apple Apple has dedicated hardware for video decode and encode for several video formats. That's why the compar

> So basically, video encoding is bad show for Apple Apple has dedicated hardware for video decode and encode for several video formats. That's why the comparisons between PCs and Macs running video editing software favor the Macs so heavily.

BoingBoomTschak 7d ago
HW and SW encoding are not comparable with regard to quality (for the same size, obviously) though. That's kinda what I meant with my quip.
- GeekyBear 7d ago
  Nothing prevents a vendor from implementing a high quality hardware encoder, just as nothing prevents the creation of a low quality software encoder. Video editing is an area that Apple dominates because PCs become a laggy mess on complicated high resolution edits. AMD has started to copy the same strategy with the recent Ryzen AI chips. They include hardware video encode/decode units as well as unified memory.
  - BoingBoomTschak 7d ago
    > Nothing prevents a vendor from implementing a high quality hardware encoder Uh yes, it's called reality. Advanced video coding techniques are just too complex, full of serial and branch heavy algos to work in decently sized and priced ASIC or even in GPGPU. Which is the reason none exists outside of very expensive special stuff for professional render/streaming farms. Not even mentioning that few coding tools are shared between codecs, so while you only need 1 CPU to handle all of them, you'd need almost an ASIC per codec...
    - GeekyBear 7d ago
      If your claim is true, you won't have any trouble finding reputable tech publications saying that the video output from Apple M series hardware is substandard in some way. I'll wait. I would recommend you find a floor plan for Apple's M series chips and take a look at how big Apple's media engine is.
      - BoingBoomTschak 7d ago
        I don't know how to say nicely that you don't realize how ignorant about the field you must seem to anyone who isn't. You'll have trouble finding such comparison for the same reason you won't find a "caterpillar vs motorbike" speed test easily. Everyone in the target market including Apple knows hardware encoding will never be about output quality. Anyway, here, I'm feeling nice. Some guy comparing the M1 Pro's HEVC encoder vs x265 (amongst others): https://colinmckellar.com/2024/01/11/video-encoder-comparison/ https://colinmckellar.com/2024/01/11/video-encoder-compariso... Here's the only graph you need to look at if you don't want to bother (encoding time vs file size at fixed perceptual quality, log scale axes): https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90.png https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90...
        GeekyBear 7d ago
        "Some Guy" just doesn't cut it. We've got five generations of Apple's Media Engine shipping in M series chips. If things are as dire as you claim, one of the many hardware reviews in reputable publications over the years would have mentioned this unacceptable quality at some point.
        timschmidt 6d ago
        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.

BoingBoomTschak 7d ago

HW and SW encoding are not comparable with regard to quality (for the same size, obviously) though. That's kinda what I meant with my quip.

GeekyBear 7d ago
Nothing prevents a vendor from implementing a high quality hardware encoder, just as nothing prevents the creation of a low quality software encoder. Video editing is an area that Apple dominates because PCs become a laggy mess on complicated high resolution edits. AMD has started to copy the same strategy with the recent Ryzen AI chips. They include hardware video encode/decode units as well as unified memory.
- BoingBoomTschak 7d ago
  > Nothing prevents a vendor from implementing a high quality hardware encoder Uh yes, it's called reality. Advanced video coding techniques are just too complex, full of serial and branch heavy algos to work in decently sized and priced ASIC or even in GPGPU. Which is the reason none exists outside of very expensive special stuff for professional render/streaming farms. Not even mentioning that few coding tools are shared between codecs, so while you only need 1 CPU to handle all of them, you'd need almost an ASIC per codec...
  - GeekyBear 7d ago
    If your claim is true, you won't have any trouble finding reputable tech publications saying that the video output from Apple M series hardware is substandard in some way. I'll wait. I would recommend you find a floor plan for Apple's M series chips and take a look at how big Apple's media engine is.
    - BoingBoomTschak 7d ago
      I don't know how to say nicely that you don't realize how ignorant about the field you must seem to anyone who isn't. You'll have trouble finding such comparison for the same reason you won't find a "caterpillar vs motorbike" speed test easily. Everyone in the target market including Apple knows hardware encoding will never be about output quality. Anyway, here, I'm feeling nice. Some guy comparing the M1 Pro's HEVC encoder vs x265 (amongst others): https://colinmckellar.com/2024/01/11/video-encoder-comparison/ https://colinmckellar.com/2024/01/11/video-encoder-compariso... Here's the only graph you need to look at if you don't want to bother (encoding time vs file size at fixed perceptual quality, log scale axes): https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90.png https://colinmckellar.com/wp-content/uploads/2024/01/VMAF_90...
      - GeekyBear 7d ago
        "Some Guy" just doesn't cut it. We've got five generations of Apple's Media Engine shipping in M series chips. If things are as dire as you claim, one of the many hardware reviews in reputable publications over the years would have mentioned this unacceptable quality at some point.
        timschmidt 6d ago
        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.