Почему ffmpeg запускают везде с 1 тредом?

1

12

в раза 3 быстрее

по идее должно в 12 раз быстрее быть

Не видел таких советов. Возможно, при кодировании на видеокарте так работает лучше, хз.

Спроси лучше там, где видел, зачем они так запускают. Может там знают.

Я такого не встречал.

Может там бенчмаркаяют чего, или ещё что…

по идее должно в 12 раз быстрее быть

Но есть нюанс.

Нет, там зависимость нелинейная

Возможно, я точно не засекал

Да везде вроде, примеры в основном были сетевые, где выход в сеть, а не файл

ffmpeg в многопоточном режиме может портить файлы или вообще отказываться собирать.

ffmpeg в многопоточном режиме может портить файлы или вообще отказываться собирать.

Зато он делает это в разы быстрее!

Если 12 тредов всего в 3 раза быстрее - это значит что эффективность работы упала в 4 раза и делать так не надо. Но вообще конечно стоило засечь время, думаю что эти в 4 раза скорее всего ты просто «на глаз» ошибся.

Почему запускают с одним - большинство, конечно, потому что так было написано в другом месте откуда они скопипастии свой пример. Если этих копипастеров выкинем (их 90% или больше), то у остальных причины скорее всего такие:

1) где-то читал что мультитред сжатие имеет более низкое качество картинки по сравнению с аналогичных настроек синглтредом, сам не проверял

2) мультитред в целом меньше отлажен и возможны проблемы, впрочем я с ними не сталкивался ни разу, при мультитред кодировании x264 кодеком (статистика большая, если умножить всё время работы ffmpeg-а на количество занятых процовых ядер, получится несколько десятков лет наверно)

Смотря что за кодек, но это очень редкий кейс, когда файл попорчен. Обычно такое встречается если делают однопроходную кодировку. При двупроходной и более, задача прекрасно параллелится по опорным фрэймам

Рекомендуют ставить как можно меньше, но чтобы кодер успевал кодировать. Если не нужно смотреть видео сейчас и файлов много, в один поток лучше кпд и энергосбережение.

В Kdenlive используется ffmpeg для сборки и там у меня регулярно не собираются видео, если использовать многопоток.

но кто сказал что это проблема ffmpeg?

я много лет занимался рипами, самое надежное это написать скрипт над чистым ffmpeg. Работало как часики, а уж когда появились многоядерные процы, все бухали цельный месяц :)

Не, может что и поломали со временем, я хз, сейчас надобности такой у меня нет

Уже сказали, но я тоже подумал, что по аналогии с тем, что аудио перекодируют в один поток, иначе (как я понял) могут быть проблемы, то может и к видео лучше так же подходить для надёжности — и возможно ffmpeg был замечен за прочей файлов.

но кто сказал что это проблема ffmpeg?

Логи.

Ого, а где это написано?

может портить файлы

Бибикать ещё не научился?

Нигде, это мой личный опыт.

по идее должно в 12 раз быстрее быть

Вот ниразу.

Вот ниразу.

На самом деле если кодирование обычное с ключевыми кадрами, то получается что часть кадров начиная с ключевого до следующего ключевого кадра является независимым и его можно кодировать независимо. Главное чтоб алгоритм разбивки на ключевые кадры не был прибит к результатам кодирования.

На самом деле если кодирование обычное с ключевыми кадрами, то получается что часть кадров начиная с ключевого до следующего ключевого кадра является независимым и его можно кодировать независимо.

И даже в этом случае это не будет ровно в 12 раз быстрее.

Нет