Есть 26 файлов mkv по 700Mb - это результат экспорта отрезка записи за неделю из системы видеонаблюдения. Требуется эти файлы склеить в правильном порядке и потом склееный файл сжать максимально без потери качества в формат avi, mp4 - не суть важно. При этом, требуется нагрузить процессор по полной, задействовать все ресурсы для выполнения работы, а не так чтобы одно ядро нагружалось задачей, а остальные простаивали. Решение ищется бесплатное или opensource, ОС - Windows. Первое, что приходит на ум, это ffmpeg, но как его правильно, с какими ключами использовать для моей задачи?
nidalee, без потери, но 4:2:0 - это занятно. Мне всегда интересно, что движет теми, кто пытается тут играть роль переводчиков с мычания на человеческий. Вы действительно думаете, что я сам не могу предположить, что хотел сказать автор, и что автору пойдет на пользу, если мы за него сформулируем его вопрос?
Ну исходник с камеры видеонаблюдения никак не может быть 4:2:2 или 4:4:4 :)
А если ffv1 не указать колорспейс, он может удариться во что-нибудь экстремальное, типа rgb.
nidalee, практика показывает, что повторение тех же параметров сжатия, что у исходника, далеко не всегда ведёт к чему-то приемлемому. Именно потому нужно заставлять того, кто хочет что-то пожать, раскрывать как можно больше информации о том, что у него есть и что он реально хочет получить. А не выдумывать за него.
практика показывает, что повторение тех же параметров сжатия, что у исходника, далеко не всегда ведёт к чему-то приемлемому
RGB весит в несколько раз больше, чем YUV, при этом новой информации от выставления RGB появиться не может, и сжатие лучше работать не начнет. Так что в случае с YUV (по крайней мере 4:2:0) исходником "-pix_fmt yuv420p" - простой багфикс для FFV1.
Moskus, я считаю, что проще ответить на вопрос, чем катить бочки на спрашивающего: "слыш ты правильно вопрос задай сначала, понял?"
Возможно, через 649 ответов мне это тоже надоест, и я буду как вы, указывать другим на ошибки в их вопросах, вместо того, чтобы отвечать.
nidalee, Moskus, насчёт сжатия. Изначально поток с камер идёт уже сжатым посредством самих камер в H264 и в таком виде попадает на видеосервер. Видеософт сервера, если я правильно понимаю, просто этот поток сохраняет в своём формате, но в неизменном виде, не меняя качество. Таким образом, при импорте отрезка с сервера, видеософт просто отдал то, что когда-то получил с камер, упаковав в MKV. Если я правильно понимаю логику, то всё уже сжато и смысла нет заморачиваться? То есть, вопрос остаётся в склейке.
fdroid, для того, чтобы ответить на ваш вопрос, мне нужно посмотреть на выдачу mediainfo любого из файлов. Если файлы сжаты, то в ответе sim3x просто меняете все параметры видео, "-c:v libx264 -preset slow -crf 22 -c:a copy" на "-c copy", вроде такого:
ffmpeg -i input_from_concat -c copy output.ts
Если софт сервера и жмет видео, то скорее всего весьма быстрым профилем, типа veryfast - есть, куда еще сжимать, если вам это актуально.
nidalee, ваша стратегия не обладает свойством сходимости, если так можно выразиться. В том смысле, что вы, на самом деле, не отвечаете на вопрос, вы отвечаете на то, что возможно хотел знать спрашивающий. А я пытаюсь это сначала выяснить, а уже потом - отвечать. Какой смысл говорить человеку, тепло ли в Амстердаме, если он хочет знать температуру в Лондоне, но забыл сказать, какую именно европейскую столицу имел в виду? Речь вроде бы всё про ту же погоду, но не там. Улавливаете? Вот теперь вы сами неизбежно требуете mediainfo, а это можно было сделать сразу.
И нет, я не указываю на ошибки "вместо" ответов, я честно отвечаю, если вопрос ясен с самого начала или был уточнен.
Вот теперь вы сами неизбежно требуете mediainfo, а это можно было сделать сразу.
Мне он нужен для того, чтобы определить, требуется ли человеку дополнительно сжимать файлы, или он может их просто объединить. На изначальный вопрос "сжать максимально без потери качества" ответ внизу уже есть, осталось уточнить.
Кстати, такой универсальный ответ пригодится следующему задающему вопрос, а если бы я дал персонализированный ответ "вам ничего сжимать не надо", то мы бы получили второй вопрос про, по сути, тоже самое.
nidalee, media info в вопросе про обработку видео нужно сходу всегда, также как код в вопросах про вёрстку и программирование, полные сообщения об ошибках - в вопросах об ошибках, модели компонентов в вопросах про сборку ПК. Полный ответ без этого принципиально невозможен. Вы это сами понимаете прекрасно.
Moskus, ну смотрите, изначально задача простая: склеить и сжать файлы без потерь качества.
На нее ответ я дал, с FFV1. Если оказывается, что человеку нужно сжатие с потерями, то на этот вопрос ответ внизу тоже есть. И тут выясняется, что человеку нужно склеить файлы без дополнительного сжатия: вуаля, ответ на это тут тоже теперь есть.
Теперь любой человек, потрудившийся поискать на тостере ответ о том, как склеить несколько файлов, получит ответы сразу на три случая: без сжатия, с сжатием, с сжатием без потерь. Вместо того, чтобы создать еще один вопрос, который с ненулевой вероятностью будет закрыт со ссылкой на этот.
В дополнение, если нет проблем со временем и нет срочности, могу предложить заменить libx264 на libx265. CRF, в свою очередь, можно будет поднять до 25. -c:a от греха поставить -c:a aac -b:a 128k, а то мало ли что там со звуком...
x265 - если оборудование поддерживает декодинг на аппартном уровне
Я думаю, что для целей архива это не обязательно, человеку нужно минимизировать размер файла и ему не жалко времени. В таком случае, когда архив понадобится, его можно в крайнем случае разжать во что-нибудь попроще за пару (десятков) минут, если аппаратное воспроизведение не поддерживается, либо найти телефон\ноутбук\etc с поддержкой H265. А вот место должно сэкономиться.
Я лично предпочитаю не aac, а vorbis, но как я понимаю звіука там может и не быть
Да, звука может не быть, об этом я не подумал. А вот vorbis вроде как не влезет в один контейнер с H265, или я не прав?
fdroid, тогда вместо -c:a copy из сообщения sim3x используйте -an
Попробуйте x265, если скорость устроит, то пользуйтесь им, а если нет, то переходите на x264.
Сложный
