Improve audio concat; cleanup temp files; add -T(temp_dir) and -P (video_pool_size) args #1
Conversation
| @@ -1,13 +1,14 @@ | |||
| #!/usr/bin/python | |||
| #!/usr/bin/env python | |||
There was a problem hiding this comment.
Поменял, чтобы скрипт нормально работал в virtualenv
main.py
Outdated
|
|
||
| logging.info("Trimming audio") | ||
| segments = AudioSegment._sync(*[audio[start:stop] for start, stop in parts]) | ||
| trimmed_audio = segments[0]._spawn([segment._data for segment in segments]) |
There was a problem hiding this comment.
Лучше использовать приватные методы класса, чем собирать весь аудиофрагмент за O(N^2) (каждый += создавал новый AudioSegment)
There was a problem hiding this comment.
Да, спасибо, звучит как и правда хорошая оптимизация
Жалко, что приходится лезть в приватные методы
main.py
Outdated
| return True | ||
|
|
||
|
|
||
| def process_chunk(workdir, args, total_segments, id, segment): |
There was a problem hiding this comment.
Раньше workdir, args и segments были глобальными и объявлялись в конце скрипта, из-за этого код было сложнее понимать.
vvd170501
changed the title
| help='number of audio chunks to be processed concurrently', default=1) | ||
| parser.add_argument('-P', dest='video_pool_size', type=int, | ||
| help='number of video chunks to be processed concurrently. ' | ||
| 'FFmpeg (without hwaccel) uses optimal number of threads by default, ' |
There was a problem hiding this comment.
Проверял с ffmpeg 4.4.2-0ubuntu0.22.04.1, количество используемых потоков равно кол-ву физических ядер процессора.
Запуск нескольких одновременно выполняющихся процессов ffmpeg не улучшает производительность, а наоборот, немного ухудшает её.
There was a problem hiding this comment.
*Относится только к предпоследней стадии - trim+concat для каждого чанка.
Для разделения видео и аудио потоков и обработки аудио в каждом чанке используется 1 поток, поэтому на этих этапах нет проблем с параллельным исполнением.
There was a problem hiding this comment.
Спасибо
Тоже хотел протестить, но никак не доходили руки
Кажется, когда добавлял эту опцию, тестил и использование многопоточности было оправданным
Сам ещё побенчмаркаю
ffmpeg по дефолту запускается с опцией threads=-1, поэтому звучит правдоподобно, что процесс будет занимать все ядра и будет конкурировать с другими
There was a problem hiding this comment.
@vvd170501, а какой порядок улучшений времени? Остались результаты замеров?
There was a problem hiding this comment.
Замерил на 30 минутах лекции в качестве 1080p60.
CPU - Ryzen 7 5800HS (8 физических ядер).
Разбиение на чанки и обработка аудио во всех случаях занимали ~8 секунд.
С одним процессом ffmpeg (5a04dcc):
$ time ./main.py -s 150 -m 50 -n 8 -p 8 -T /tmp/ramdisk/ -i ls4_30min.mkv -o lec4_trimmed.mkv
real 6m10,282s
user 50m56,566s
sys 0m46,125sВо время выполнения trim+concat каждое из 16 логических ядер используется на ~50%, ffmpeg использует ~1 ГБ памяти, load average (1min) ~=9.
С 8 параллельными процессами ffmpeg (c9bc294):
$ time ./main.py -s 150 -m 50 -n 8 -p 8 -T /tmp/ramdisk/ -i lec4_30min.mkv -o lec4_trimmed.mkv
real 7m25,505s
user 110m17,434s
sys 1m48,683sВсе логические ядра загружены на 100%, используется 8 ГБ памяти, load average (1min) ~=70.
C ускорением на RTX 3060 mobile (мб попробую сделать PR, но нужно как-то добавить проверку на доступность nvenc):
$ time ./main.py -s 150 -m 50 -n 8 -p 8 -P 2 -T /tmp/ramdisk/ -i lec4_30min.mkv -o lec4_trimmed.mkv
real 2m22,735s
user 2m0,605s
sys 0m8,618s
No description provided.