Anon (lkasdfj.delete@this.fjdksalf.com) on June 16, 2022 3:06 pm wrote:

> For those scratching your heads, this dude's an armchair quarterback who believes the main reason
> Apple's chip architects put in many hardware codec blocks was to accelerate single stream encode/decode
> to a higher degree than a single block could on its own. He just *knows* it must be possible to
> split the work into multiple threads so that multiple codec "cores" can collaborate on it - some
> software codecs are multithreaded so obviously that must be possible with any hardware codec design
> too. Therefore, according to him, if Apple's system can't do that, it must be a terrible and embarrassing
> failure of communication between hardware and software departments.

It is possible to split video on GOP boundaries and encode in parallel, even over a cluster. For example, here's what Netflix does:

"The media content is broken up into smaller chunks. Each of the chunk is a portion of the video, usually about 30 seconds to a couple of minutes in duration. In a massively parallel way, we encode these video chunks independently on our servers. Once all the chunks have finished the encoding process, they're reassembled to become a single encoded video asset."

Maybe this can't be hidden under the existing VideoToolbox API so it probably requires app changes. And maybe those changes haven't been made which (outside of Final Cut) isn't Apple's fault. But I can understand why customers might be confused or frustrated if they are waiting on a single-stream encode workload which isn't faster on higher-end Macs.