Decoder::open picks VideoToolbox or the software decoder from the H.264 profile alone. #583 measured that choice for export and changed it there, introducing DecodeIntent so the preview keeps the old arbitration untouched.
That was a deliberate refusal to generalise, not a conclusion. The preview has never been measured at all.
The two are not obviously the same problem:
- The export wants throughput and nothing else. It won by 28.7 % on the software decoder.
- The preview wants to hold a cadence and to seek — the user scrubs. A hardware decoder's fixed per-frame latency is a bad deal at 200 fps and possibly a fine one at 60 fps, and seek behaviour after
avcodec_flush_buffers was not compared at all.
- The preview shares the machine with the editor UI.
thread_count = 0 gives the software decoder every core; that may cost more in UI smoothness than it gains in decode headroom. On battery it is a straight loss.
What would settle it, roughly: a scrub-heavy preview session with frame-pacing and CPU sampled per backend, on both power sources. Until someone does that, DecodeIntent::Preview should stay as it is.
Decoder::openpicks VideoToolbox or the software decoder from the H.264 profile alone. #583 measured that choice for export and changed it there, introducingDecodeIntentso the preview keeps the old arbitration untouched.That was a deliberate refusal to generalise, not a conclusion. The preview has never been measured at all.
The two are not obviously the same problem:
avcodec_flush_bufferswas not compared at all.thread_count = 0gives the software decoder every core; that may cost more in UI smoothness than it gains in decode headroom. On battery it is a straight loss.What would settle it, roughly: a scrub-heavy preview session with frame-pacing and CPU sampled per backend, on both power sources. Until someone does that,
DecodeIntent::Previewshould stay as it is.