Lasse Collin wrote: > I guess that your idea is to use --no-adjust to catch situations where > the specified settings are too high even for single-threaded operation, > and use more than one thread when the memory limit allows.
Yep. (I had forgotten that explicitly using only one thread produces different output than the threaded encoder writes, though. Is there a way to explicitly request the threaded encoder with one thread, for testing?) > I don't know if someone would want to use --no-adjust to prevent xz > from scaling down the number of threads. Maybe your use case is more > likely. I would be even happier with a way to specify - try to scale down the number of threads to avoid using more than 512MiB of memory - error out (or scale down, depending on my mood) if single-threaded operation requires more than 1024MiB. So I guess my patch is not so great, and it would be better to have a separate --very-soft-memlimit option (like you suggested) that indicates a preferred memory footprint to try to achieve without sacrificing the quality of the output.
