Комментарии 18
за этот день оказался 321 видео файл и как говорится «бобик сдох».
Непонятно, почему на таком количестве файлов память заканчивается. Каждый файл в память целиком декодируется?
Не совсем, но похоже, на каждый файл MoviePy запускает отдельный экземпляр ffmpeg.
Не знаю, как этот MoviePy устроен. Если бы я делал свою программу для склейки, то можно делать так: разбить последовательность файлов, которые нужно склеить, на фрагменты, допустим, по 10 штук. Каждый фрагмент склеить в промежуточный файл с перекодированием в один и тот же выходной формат. В конце все полученные промежуточные файлы склеил в один выходной уже без перекодирования.
А то и просто каждый файл по одному в промежуточный файл с одним и тем же выходным форматом перекодировать, а потом их разом в один конечный файл склеить без перекодирования через ffmpeg -f concat - в текстовый файл можно хоть 500 видеороликов засунуть.
Не пробовали делать libx265 + qp 0 для финального результата? У меня всегда получался размер меньше исходного (исходный после декодирования уже урезанный по качеству, и кодек эти узкие места эффективно использует, не привнося новых)
Пробовал, да. Размер меньше получается, но и время обработки существенно увеличивается. А в поставленной задаче для меня скорость была немного важнее чем финальный размер файла.
(PS: в утилите и библиотеке можно задать кодек через переменную окружения FFMPEG_CODEC)
Тогда можно попробовать libx264 + qp0 + какой-нибудь не совсем душманский пресет. Подозреваю, что и тогда размер будет не сильно больше, чем было изначально. Ну тут смотря, как отработали фильтры - `-r ...` не должен сильно влиять на размер сжатого; правда, результат работы такого фильтра очень не очень, это ж просто дублирование/удаление кадров со всеми вытекающими (minterpolate есть для желающих лучшего)...
исходный после декодирования уже урезанный по качеству
Просто декодирование качество разве урезает?
Кодек H265 размер сжатого файла по сравнению с H264 может уменьшить при том же визуальном качестве, но не в разы, а раза в полтора-два обычно.
Нет, урезает конечно кодирование. Но повторное перекодирование тем же кодеком в режиме "без потерь" должно дать результат, сопоставимый по размеру с исходным файлом (а с лучшим кодеком - меньшего размера). Я все это к тому, что потеря качества была один раз; потом деинтерлейсер, стабилизатор и фреймрейт какие-то свои изменения привнесли, но основной источник потери качества и уменьшения энтропии (квантизация) остался, и повторное сжатие результата даже без потерь должно бы быть сопоставимым по размеру с исходным файлом. Я все это к тому, что наверное нет смысла повторно пережимать с потерями.
А зачем вы на каждом шаге аудио во flac перекодируете? Не проще ли вообще его выкинуть из временных файлов и добавить лишь на последнем (или предпоследнем) шаге, когда ролик готов к склейке с остальными? Ну или хотя бы просто копировать аудио без его перекодирования?
Возможно я что-то делал не так, но в форматах без сжатия у меня терялась синхронизация звука и видео (например при смене частоты кадров видео). Flac без потерь и на фоне операции перекодирования видео, перекодирование аудио вообще не заметно. При этом можно быть уверенным, что ничего нигде не потеряется.
ffmpeg умеет чейнить фильтры, так что деиниерлейс, стабилизацию и поворот/пад можно сделать за один заход, сэкономить время. Так же уже на этой стадии можно закодировать в таргетный кодек видео, чтобы потом можно было конкатерировать ролики без ещё одной стадии перекодирования, для этого в кодек x264 надо передать опцию stitchable, чтобы он не оптимизировал sps/pps.
делать так же для аудио не рекомендую - там будут нюансы с дополнительными кадрами тишины, проще в промежуточном видео использовать flac.
Проблема в том, что стабилизация выполняется в два прохода (Можно ли их чейнить? У меня не получилось.) и она должна быть между этапами интерлейса и поворота, так что их тоже не объединить.
С кодированием на последнем этапе в финальный кодек, я игрался, но есть пара нюансов, для разных видео фрагментов (напоминаю, что они очень разнородные) этапы могут различаться. Плюс к этому вылезали разные артефакты, например были проблемы с расчетом длины видео. Но я не знал про stitchable, попробую, спасибо, возможно мне как раз этого не хватало.
А что мешало закинуть всё в вегас крайних версий?
Здравый смысл, скоротечность человеческой жизни и отсутствие желания посвятить этому монотонному ручному процессу несколько лет.
Не представляю честно говоря каким образом это может занять много времени если можно просто выделить все видео и закинуть их на таймлайн+на весь таймлайн накинуть деинтерлейсер+стабилизатор, рендер займёт некоторое количество часов, ну тут уж что поделаешь, если видосы все по папкам/архивам распиханы и на каждый день своя папка/архив тут уже да, согласен.
Текст стоит несколько раз перечитывать перед публикацией. От орфографии и пунктуации кровь льётся из глаз и мешает читать код.
Склеить несколько видеофайлов, что может быть проще…