macOS export: none of h264_videotoolbox's speed knobs move its throughput #588

Negative result. VideoEncoder::try_open sets bit_rate and nothing else — no profile, no realtime, no prio_speed, no max_ref_frames. Since the export turns out to be bound by encoder throughput (see the encode-thread issue), the obvious question is whether the encoder is simply configured slowly.

It is not. Same machine, same content (the composited 1080p60 3600-frame render itself), h264_videotoolbox at 8 Mbps, -f null so muxing is out of it:

prio_speed and an explicit profile are inside the noise. realtime makes it slower, which is the opposite of what the option name suggests and is worth knowing: it is a hint that encoding should happen in real time if not faster, i.e. a latency hint, not a throughput one. It has no business on an export path.

(These figures include decoding the input — measured separately at 1 864 ms — so the encoder alone runs at roughly 228 fps.)

What this closes and what it leaves open

Closed: there is no free throughput in the encoder's option surface. Anyone reaching for realtime to speed up an export should not.

Left open, and deliberately not attempted here because both are product decisions rather than performance ones:

• Bitrate. 8 Mbps is derived from output area (bit_rate = w*h*8_000_000/(1920*1080)). Whether a lower target encodes faster on this silicon was not measured; if it does, it trades file size against export time and somebody has to choose.
• constant_bit_rate, spatial_aq, max_ref_frames. These change the picture, so comparing them needs a quality methodology (PSNR/SSIM against the composited source at matched bitrate), not the byte-equality check used elsewhere. Out of scope for a pure-speed pass.