Wes Felter (wmf.delete@this.felter.org) on June 16, 2022 4:57 pm wrote:
> 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.

Note that this might require prohibitive amounts of memory to store the video. IF you had 10bit 4:2:2 YUV (16 bits per luma, 16 bits per chroma U&V) colorspace, decoded video consumes almost 8 GB per 240 frame (10 secs) GOP at 4K. And to use 4 engines in parallel, you would use four such buffers.
Forget using "couple of minutes" long GOPs. This way. Such long GOPs would be major mess for editing video anyway. Actually, all non-intra videos with GOPs are trouble already?

It's true that such long GOPs are probably less common in pro/braodcast encoding. But still, you don't want to consume that many gigabytes on Apple M1/M2 devices that have just 8-24 GB of total RAM. Intra formats though? Doable there I guess.