A única coisa que você está codificando é o áudio, e a maioria das bibliotecas de codificação de áudio existentes é de thread único. Isso é mais provável porque a codificação de áudio já é muito rápida como um aplicativo de thread único (quando comparado à codificação de vídeo) e não usa muita memória, por isso é possível codificar cada arquivo usando um único thread e apenas iniciar como muitos processos separados, conforme necessário, para saturar totalmente a CPU. Fator no fato de que o multi-threading também não necessariamente resulta em melhorias de desempenho linear e você provavelmente tem a razão pela qual os desenvolvedores da maioria dos codificadores de áudio não acham que o multi-threading é uma alta prioridade. Eu sei apenas de dois codificadores de áudio que implementam multi-threading - LAME MT para MP3 e pflac para FLAC - e ambos são modificações separadas que não fazem parte das principais bases de código dos projetos dos quais derivam.
Quanto ao uso da CPU, com hyper-threading, você tem 8 núcleos lógicos e um oito de 100% é 12,5%, o que não é muito longe de seu valor de utilização de 15%. Eu não tenho certeza porque o sistema não está mostrando uma carga de 100% em qualquer um dos núcleos, talvez o sistema operacional esteja movendo o processo entre os núcleos para nivelar a carga ou algo assim.
Se você precisar codificar um grande número de arquivos, convém escrever um script que gere múltiplos processos FFmpeg para codificar vários arquivos ao mesmo tempo. Eu tenho muito pouca experiência em programação / script, mas eu sei de uma ferramenta de código aberto que aplica a mesma lógica para otimização de imagem: picopt . Então, se você precisar de um ponteiro sobre como fazer isso em Python, pode dar uma olhada no código-fonte do picopt.