Вот взял я видос с быдлодевайса, и надо мне его пережать каким-нибудь ffmpeg -preset veryslow, чтобы это говно меньше места занимало, да так, чтобы сколь-либо ощутимых потерь не было, либо их не было вообще. Какой существует самый рациональный способ это сделать, чтобы не ебать себе мозги битрейтами конкретных файлов?
Цоперайт © 2010-2016 @stiletto.
@spoofing решал ту же проблему, тоже пробовал ютуб - говно полное, всё в квадратах;
остановился на ффмпег с x265 - пиздец медленно на старом проце без хардварной поддержки;
чотам у AV1?
Если тебя устраивает размер файлов, то не пережимай. Небось, не свадьбу на дорогущую камеру сжимаешь, а трясучку, которая уже превращена в артефакты аппаратным кодером для низкопотребляющих систем. Иначе просто кодируй с таким CRF, который ублажает твой диск размером, а глаза — качеством (в статичных и динамичных сценах, на хорошем мониторе). -preset veryslow ничего заметно не изменит, он для успокоения совести нужен, когда время кодирования не имеет значения.
@komar Видео уже сжато с огромным коэффициентом и потерями, дорогой. Если оно будет на 10% меньше места занимать, смысла в дальнейшей порче нет. А иначе, как всегда, ты должен выбрать сочетание размера и уровня потерь, которое тебя устраивает. Получить файл на порядок легче и без видимых отличий (в повседневном использовании) можно только из качественных исходников, изначально рассчитанных на редактирование или проекцию на большой экран. Можешь инвестировать процессорное время в перспективные кодеки, если считаешь, что материал того стоит.
@komar тфв информационные потоки вокруг надоедливы и пусты как жужжание комара
@komar Нет, я тебя учу.
@ceyt да он же Н Е О Б У Ч А Е М Ы Й
@komar На тхинкпаде ты заметишь разницу, только когда у тебя цветность пропадёт.
Откуда я должен знать, какой уровень потерь ты считаешь нормальным, и для чего тебе это всё нужно будет потом? Выше и написано: выбери уровень качества, который считаешь нормальным, и смотри, каков выходит размер. Из результатов делай вывод о целесообразности перекодирования.
@ceyt палю: он хочет не смотреть, а чтобы было "сделать заебись"
@komar Команду ты сам написал. Устраивает тебя CRF 22 — используй его или проверяй большие коэффициенты. Возьми по минуте светлых и тёмных фрагментов, с тряской и без, и оцени результат во всех случаях, в ffmpeg тривиально время начала и длительность добавляется. Если завтра тебе нужно будет вывести шедевр на большой экран, и там он будет выглядеть как говно, только твоё собственное восприятие можно будет в этом обвинить.
Кодирование без потерь можно оптимизировать, приближая к идеалу (по какому-то набору параметров). Кодирование с потерями не имеет универсальной целевой функции, потому что вес каждого параметра отличен для разных применений (кому-то нужна скорость, у кого-то фиксирован битрейт, кому-то нужен минимум потерь и ограничение битрейта сверху, и т. д.).
@komar Ты понимаешь, что твоё «не вижу разницы» субъективно? Ты понимаешь, что исходное видео может быть уже сжато настолько серьёзно, что его лучше не трогать, чтобы дальше не портить?
Жми свою хуйню как хочешь, но не делай вид, что у тебя при этом мозг работает.
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf
@komar Ты указываешь CRF и скорость (через -preset), остальное умный алгоритм делает сам. Куски для оценки вырезаются -ss и -t. Для видео тебе больше ничего не нужно.
@komar ты можешь снизить итоговый размер файла, вырезав из него часть метаданных - это легко реализуется командой
-map_metadata -1@komar Именно, я артист, я работаю на вас, и хуй кто оценит, вам даешь хорошую комедию и вы жрете хорошую комедию, даешь говно и вы говно жрете. А потом обязательно плюетесь и распространяетесь, как сожрали говно, но жрать продолжаете, конечно, вы же общество потребления с воспаленным умом и фантазией уровня школодвача, шутками за тристо и прыщами на ебле, проглядывающие в монитор сквозь копны свисющих немытых по неделе волос.
@komar Тебе больше ничего не нужно. То, что запишет встроенный микрофон, и в дефолтном AAC на 128 кб/с неплохо звучит.
@komar Крутить ручки и указывать другие параметры кодирования.
@komar весьма похоже! но вообще, это одна из манькопаст
@komar Тебе не нужно вписаться в размер, не нужно вписаться в битрейт, не нужна совместимость с просмотром онлайн или на старых устройствах. Тебе нужно только выбрать CRF, который ты определяешь глазами (но можешь и опрос создать на бнвачике, у нас суверенная демократия).
@komar Совершенно верно, ты выбираешь CRF, и у тебя выпекаются файлы примерно одинакового качества. Их битрейт ты не знаешь, поскольку он тебе и не интересен.
@komar CRF — это не задание битрейта другим способом, это задание обобщённого уровня потерь. В сложных сценах битрейт будет больше, в простых — меньше. CRF ты подбираешь один раз (например, по визуальной оценке кодирования сложной сцены), потом спокойно обрабатываешь все остальное с полученным значением.
Кодек сам не знает, как должно выглядеть то, что тебе нужно.
https://slhck.info/video/2017/02/24/crf-guide.html
@komar Да ты можешь решить уже, какая циферка тебе подойдёт?
@komar Картинка внутри не одна и та же, чему удивляться. Стратегии распределения битрейта и объёмы буферов для анализа могут отличаться.