FFmpeg и общий кодирования видео тред №7 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
27/07/22 Срд 09:08:01
№
1
В прошлый раз мы срались за аудиокодеки весь тред.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (во многом устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Гайд по кодированию от анона из треда №5 (принимается критика, её было много в треде №6): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.hk/s/res/3144406.html
Надо было написать, что в x264 я тоже пробовал кодировать, но нихуя не поменялось. Как было 12 отсутствующих/одинаковых кадров в начале с -c:v copy, так с -c:v libx264 и осталось.
Вики что-то там кукарекает по поводу frame-accurate seeking, когда по факту нихуя не frame-accurate.
Где её было много, я вроде всё подправил то что сказали
Нет, они плохо жмут. Особенно второй, даже хуже первого. ffv1
>ffv1
И как им СЖИМАТЬ? Не могу чет найти нормальных описаний параметров.
-ss вместе с -noaccurate_seek перед входными файлами
Сначала нарежь видос на сцены при помощи scenecut. Это важная метаинформация.
Внутри большинства сцен хватит одного-двух кадров. Если сцена динамичная - тогда все кадры хуярить. Динамику сцены можно посчитать по векторам движения.
На опорные кадры забей, для смыслового содержания разницы никакой.
Я хочу прикрутить туда vidstabtransform, и если обычные видео снятые с рук он делает очень плавными и ровными, то тут (возможно из-за постоянного движения дна, а возможно из-за нерегулярного фреймрейта) оно почти не работает и всё дёргается. Можете подсказать как такое обработать, и насколько хорошо vidstabdetect работает с переменным фреймрейтом? У него просто в настройках количество кадров для сглаживание, хотя для такого видео сглаживание должно быть не по кадрам, а по меткам времени...
Может быть стоит самом получить метки времени кадров и обработать файл после vidstabdetect с корректным сглаживанием?
Опять же, что там условный 265 выжмет после 264? Очень интересно.
Боже как сложно.
> Хочу анализировать ролики с помощью нейросети на смысловое содержание
Смысл чего искать планируешь и как планируешь определять в чём смысл?
>на чем я жму
Жмешь на камне в 10 бит с пресетом veryslow, это основа.
>Или карта так же хорошо как проц не может - почему?
У кодеков видеокарт реализация энкодера и пресеты почти полностью зашиты непосредственно в железо, потому что при разных пресетах почти всегда применяются разные алгоритмы. Ну и соответственно, у видеокарт можно лишь выбрать те пресеты, которые решил в них зашить вендор, и часто эти пресеты не самые эффективные из возможных. На камне же ты можешь исполнять любые алгоритмы и выбирать сложность задачи так, как тебе хочется, достигая наилучших результатов ценой более продолжительного времени кодирования и тепловыделения.
Честно говоря это все довольно сложно.
Поиск и выделение фрагментов рекламы по логотипами и характерным образам. Или автоматическое разбиение по ключевым фрагментам видео (у порнхаба нейросетка научилась автоматом маркировать таймкоды сцен). Или просто поиск нужной сцены в ролике по ключевым словам.
Есть расширение, которое маркирует рекламу на ютьюбе, можно взять оттуда таймкоды рекламы, вырезать их из роликов и получить выборку с рекламой и без неё. А потом обучить нейросеть находить потенциальную рекламу. Можно конечно просто скачать субтитры и анализировать по ключевым словам, но автор ролика может просто отключить субтитры. И тогда их придётся генерировать самому. Но бывают рекламы без звуков, только образы или музыка с надписью. Поэтому их нужно анализировать нейросеткой. Но анализировать весь ролик будет слишком расточительно. Вот и думаю как оптимизировать, если отбирать только важные кадры.
>>3182332
> Жмешь на камне в 10 бит с пресетом veryslow, это основа.
Это хуйня полная, а не основа. Медленне чем slow не надо использовать
У тебя наверное двухъядерный интел вместо процессора, я тебя правильно понял? На моем 5700ж h265 10 bit кодируется в 5 фпс.
*при битрейте 1000k
При 8000k 2 фпс
И дальше что с какой скоростью оно кодируется, еблан? Когда av1 с такой же скоростью выдаст намного лучшее качество
av1 на любой скорости выдаст лучшее качество, додич.
>алгоритмы. Ну и соответственно, у видеокарт можно лишь выбрать те пресеты, которые решил в них зашить вендор
У меня, скажем, 1050 от ноунейм вендора и ещё 630 встройка. Как можно луркануть на счёт того, что она поддерживает и что нет? Есть ли специализированный сайт с базой данных?
Хотя что-то мне подсказывает, что на моей старушке 265-й все равно кодировать не будет, про встройку хз, есть ли смысл о ней говорить вообще. Если декодировать одно из двух будет и то хорошо.
>от ноунейм вендора
От вендора чипа видеокарты, имеется в виду. У nvidia чип-кодировщик называется nvenc, у intel это qsv, у amd - vce/vcn. Для каждого поколения видеокарт там свои приколы, на англ википедии вроде есть чуть подробнее.
Но на самом деле сжатие на видеокарте в лучшем случае реально будет сопоставимо где-то с пресетом medium или около того на камне.
А выходной размер файла будет отличаться в разы, что-ли (medium vs slow vs very slow)? Мне просто интересно, жизнеспособно ли сжатие на карте для хранения фильмов или аппаратное ускорение все же предназначено больше для стримов и монтажа.
Алсо камень у меня 4/4 пиздос из 2017. Стыдно даже модель писать итт, кодировать на серьезных пресетах он будет сутками.
Спасибо за ответы.
Он размытое говно выдаст, дебич
>>3182452
Нет, размер файла одинаковый, а картинка выглядит лучше, если медленнее
Просто купи жёсткий диск, это намного быстрее выйдет, они стоят копейки
>Просто купи жёсткий диск, это намного быстрее выйдет
Наверное ты хотел сказать купи и качай туда полновесные ремуксы? Да, быстрее. Но я интересуюсь из любопытства, мне просто нравится изучать технологии даже без практической пользы для себя.
При одинаковых (по скорости кодирования) пресетах и прочих равных av1 всегда будет выигрывать x265, ебанашка.
>>3182452
>А выходной размер файла будет отличаться в разы, что-ли (medium vs slow vs very slow)?
Сразу начну с того, что разницы в разы ты здесь не увидишь никогда. Разница будет зависеть от того, как ты кодируешь, если по битрейту, то отличаться будет главным образом само качество картинки, если указываешь качество через crf/qp, то отличаться будет размер файла. Ориентируйся на то, что при одинаковом качестве файл, пожатый с пресетом medium, будет весить на 5-15%, максимум - на 20% больше, чем с veryslow.
>жизнеспособно ли сжатие на карте для хранения фильмов
Всем в общем-то похуй, чем и как ты там будешь жать, если для себя, но если будешь шарить с кем-то и у тебя есть нормальный проц, то veryslow - это базис.
> av1 на любой скорости выдаст лучшее качество, додич.
>>3182490
> При одинаковых (по скорости кодирования) пресетах и прочих равных av1 всегда будет выигрывать x265, ебанашка.
Что за дебил сука
Причём даже тут напиздел, x265 чаще будет выглядеть лучше и быстрее
> veryslow - это базис.
Точно дебил.
Going from medium to slow, the time needed increases by about 40%. Going to slower instead would result in about 100% more time needed (i.e. it will take twice as long). Compared to medium, veryslow requires 280% of the original encoding time, with only minimal improvements over slower in terms of quality.
>x265 чаще будет выглядеть лучше и быстрее
Что тяжелее, килограмм железа или килограмм пуха, ебло? Глаза раскрой сука и читай >>3182490
>>При одинаковых (по скорости кодирования) пресетах и прочих равных
>Точно дебил.
>нерелейтед паста с вики
Ещё раз тебе сука рекомендую вынуть хуи из глаз и прочитать, почему я так сказал >>3182490
>>если будешь шарить с кем-то и у тебя есть нормальный проц, то veryslow - это базис.
> Сразу начну с того, что разницы в разы ты здесь не увидишь никогда. Разница будет зависеть от того, как ты кодируешь, если по битрейту, то отличаться будет главным образом само качество картинки, если указываешь качество через crf/qp, то отличаться будет размер файла.
Тоже пиздёж, файл с preset ultrafast crf 30 будет выглядеть намного хуже, весь в пикселях чем preset slow crf 30
Хуй будешь? ultrafast какое отношение к разговору имеет? А вообще ладно, тут признаю, запизделся немного. Качество будет немного разным из-за разных использованных фич, но на указанном диапазоне пресетов не то что бы очень сильно. Изначально хотел написать только про qp, там эта разница намного менее заметна.
> у порнхаба нейросетка научилась автоматом маркировать таймкоды сцен
Ничего себе. Я думал, это вручную выставляется. То-то иногда вообще не к месту, как будто даун маркировал. Но в целом точность впечатляет. Так вот почему анал почти не маркируется, определить сложно.
А в конечном результате для чего тебе это надо? Ты для себя собрался вырезать рекламу из роликов или сам делаешь публичный/коммерческий проект?
> А в конечном результате для чего тебе это надо? Ты для себя собрался вырезать рекламу из роликов или сам делаешь публичный/коммерческий проект?
Ну коммерческий вряд ли, база данных с таймкодами рекламы запрещает делать коммерческие проекты на его основе, но если получится сделать что-то путное, то почему бы не опубликовать. А пока я только присматриваюсь, как лучше все это реализовать. Если кто-то сделает что-то похожее раньше и опубликует для всех, то буду только рад.
Изначально только пользователи маркировали, а потом нейросеть обучилась на их выборке и теперь сама может таймкоды ставить.
В мобильной лисе/хроме видно только превью, сами файлы не проигрываются.
>>3182490
Тут можно подробнее про ручную настройку битрейта и crf/qp? Про crf знаю, что алгоритмы анализируют каждый кадр и меняют битрейт в соответствии со сложностью сцены; qp в этом плане тупее и все кадры жмёт одинаково, так как постоянная квантизация.
Зачем в этой прекрасной картине пользователь с хотелками по битрейту? Зачем руками регулировать поток, а не довериться crf?
Про пресеты вроде понятно. Чем дольше процессор обрабатывает кадр, тем лучше качество и сжатие, верно? То есть субъективно картинка лучше и размер на выходе чуть меньше, так? Вроде логично.
>файлы не проигрываются.
Скачай и открой в нормальном плеере, если интересно. Браузеры не всегда поддерживают 10-битный h265 (если вообще поддерживают без расширений, лол).
>Тут можно подробнее про ручную настройку битрейта и crf/qp?
Ну тут на вкус и цвет на самом деле, если нужно пожать сильнее в ущерб качеству - ставишь циферку crf/qp побольше, ну и соответственно наоборот. Для каждого кодека и пресета результаты будут чуть отличаться, поэтому конкретных цифр давать нет смысла, отталкивайся от дефолтных.
>Зачем в этой прекрасной картине пользователь с хотелками по битрейту?
Очевидно, это для тех случаев, когда очень важно иметь постоянный битрейт. Например для стримов на твиче/с камер наблюдения. Ну то есть когда сам факт наличия непроёбанной видеозаписи гораздо важнее её качества в целом. Так и сети проще, и рассчитывать нагрузку удобнее. Или если необходимо иметь файл ровно заданного размера, но позволить совершить несколько прогонов с рандомным crf ты себе не можешь.
>Чем дольше процессор обрабатывает кадр, тем лучше качество и сжатие, верно?
Да, в целом всё так и есть.
Видео : AVC, 1280x720(16:9), 30.000 fps, 3 000 kb/s (0.017 bit/pixel)
Аудио: AAC, 44.1 kHz, 2 ch, 128 kb/s, CBR
Аудио: opus, 48KHz, stereo, ~10kbps
Видео: av1, 1280x720, 10fps, ~25kbps
Я просто у видел такое на торрентах, и тоже захотел свои видосы пожать.
Такой скрипт для ffmpeg вообще трудно написать? я просто не пользовался им никогда
1 - Аппаратный VP9 энкодинг на интелах 12 поколения совсем говно? Стоит ли тратить время на его пердолинг?
2 - AV1 хвастаются поддержкой синтетического грэйна в моё время x264 такое мог, хз что они хвастаются. Так вот, можно скормить энкодеру 2 потока - отденойзеное видео и шум для анализа. Не доверяю я встроенному денойзеру, я уверен что смогу отфильтровать лучше. Плюс на чистое видео можно ещё наложить шарпа/контраста и прочего, что страдает при денойзе.
> в моё время x264 такое мог, хз что они хвастаются
Где, покажи
>>3184026
> AV1 хвастаются поддержкой синтетического грэйна
А что это?
Похоже я малец спиздел. Film Grain Modeling payloadType film_grain_characteristics есть в стандарте, и был в экспереминтальных билдах энкодера. Но видимо не прижилося... в те времена вообще был тренд на тотальнейший денойз.
>>3184037
Film Grain - шум плёнки, добавляет теплоты и ламповости и перцептуально - деталей фильму.
>добавляет теплоты и ламповости
Хуйня какая. Может у тебя ещё интерлэйс теплоты добавит? Артефакты мпег сжатия? Эти медиапердолики совсем поехали, одни песок на виниле слушают, другие в зёрна на плёнке вглядываются.
Очень неплохо. Но все-таки картинка статичная большинство времени.
> Такой скрипт для ffmpeg вообще трудно написать
просто батник написать обычный можно. Либо ffmpeg media coder использовать он обычные список команды на кучу видосов может сделать, причем паралленно и не надо прописывать все пути, даже папки сам создает как хочешь.
Проц 12700к, поддерживает вроде
ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
Попробовал эту хуергу, но супер долго, у меня на видеокарте меньше чем за минуту декодит, а тут вообще хуеву тучу времени
Есть гайд как енкодить на видюхе максимально в маленький размер?
Мяу, а оно поддерживает все прелести vp9, или это будет как с nvenc, что формально это h264, но нет crf-режима, и при том же размере качество сильно хуже, чем на процессорном варианте, которые все доступные h264 штуки использует?
Я не шарю
Мне надо сильно сжать видос
И чтоб видюхой
Пиздец, енкодило больше 10 минут и файл на выходе не 150мбайт как на ffmpeg -i ... -c:v hevc_nvenc без параметров вообще, а 200+
Интересные гайды
Я знаю, что такое Film Grain, я спрашивал, что такое синтетический грейн и какая ему требуется поддержка от кодека?
А ты хотел чтобы тебе параметры сжатия вслепую сказали не зная что у тебя за видео?
Если ты хочешь конкретный размер - указывай битрейт, получишь хоть 40 мб; если хочешь конкретное качество - указывай crf.
Не, забей, я решил через видюху делать, ибо уж слишком долго получается что в VP9, что уж тем более в AV1
Там зивон на 64 ядра нужен, лол
На QSV.
>>3184100
Ещё бы тебе программно быстрее было.
>>3184101 >>3184105
Тащемта гайд есть, он короткий и простой: выбери что-то 1.
>>3184102 >>3184107 >>3184132
Ути какой впечатлительный нафаня, 10 минут его в шок повергли. Мы тут сутками энкодим, если надо.
> Мы тут сутками энкодим, если надо
Ну и зачем тогда этот энкодинг нужен если он такой долгий?
Чтобы все охуели от того как мы можем
Bruh
Ну ясненько
А почему у меня на некоторых видосах for i in (*) do ffmpeg -i "i" -c:v hevc_nvenc -preset slow "out/%%~ni_enc.mp4" вот эта хуерга после обработки размер больше начального выдаёт
Где-то в процентах 20
В остальном заебись, раза в два меньше
А с чего вдруг ей выдавать размер меньше, если ты её об этом не просишь?
Какой кодек с каким битрейтом сильнее всего сжимает музыку совсем без слышимых потерь? Обзавёлся бинарью с --enable-libfdk-aac, стоит ли жать -c:a libfdk_aac -profile:a aac_he?
Какой командой записывать экран во время игры? Разрешение 4к, 16-22 Гб в час будет хорошим результатом, сильно заметных артефактов быть не должно. Определить, свободен ли больше ЦП или ГП я не смог - во время записи с кодированием на видеокарте и ЦП и ГП в диспетчере задач были нагружены меньше 50%, при этом на экране и особенно на записи были лаги, а после завершения записи процесс ffmpeg некоторое время грузил ЦП под сотку (видимо склеивал уже созданное видео с тем, что вовремя не успел сжать и отложил на потом). Двухпроходное кодирование допускаю, но слушать концерт кулеров больше часа не буду, лучше пожертвую размером.
Короч потыркался немножко с vp9. Хардварный энкодер не заработал, но и софтварно кодируется достаточно быстро. Но вот качество но моём таргет битрэйте 2-2.5mb/s для сильно грэйни исходника не оче. Порой оно сохраняет грэйн, порой мылит, но чаще просто выдаёт высокочастотный DCT-шум.
Короч для грэйна
>>3184111
Синтетический грэйн это грэйн который добавляют пост-процессом. Энкодер по идее должен анализировать кадр и записывать информацию о характеристиках шума, типо частоты, интенсивности. Конечно такое можно приделать просто фильтром в плеере, но тогда грэйн будет всегда одинаковый.
> Энкодер по идее должен анализировать кадр и записывать информацию о характеристиках шума, типо частоты, интенсивности
Никогда не слышал о таких функциях.
Интересно, тестировать с такими скоростями я это, конечно, не буду, но за ум всё-таки взялись, спустя десять лет после покупки вп.
Попробовал SVT-AV1 с грэйном.... Ну что-ж сказать, это фиаско. 15 лет пропихивать в стандарт грэйн, и так отвратительно его делать - это надо постараться. Не удивлюсь если это внутренний саботаж. Во первых встроеный денойзер мылит так что глаза вытекают, что-то на уровне скриптов из 2002 года. Во вторых характеристики шума не имеют никакого отношения к характеристикам грэйна - там обычный гаусс-нойс. В третих - какой-то байтоёб(хотя известно какой) решил что можно сделать текстурку нойза 64x64 и этого хватит на весь fhd\qhd\uhd фрэйм. В итоге даже на не сильно больших плоских площадях тайлинг режет глаза.
Во первых где семплы?
Во вторых почему ты не попробовал aomenc?
> В третих - какой-то байтоёб(хотя известно какой) решил что можно сделать текстурку нойза 64x64 и этого хватит на весь fhd\qhd\uhd фрэйм.
А это уже от декодера зависит. Если dav1d обосрался, нужно попробовать aomdec. И похуй что производительность просядет, нужен фрейм от референсного декодера что-бы делать выводы касательно кодека av1.
>Во первых где семплы?
Да вы-ж меня обосцыте узная что я кодирую... Ладна, вот сравнение https://imgsli.com/MTE5NzA5
crf 24, битрэйт примерно 3 мегабайта. Грэйн жутко тайлит, денойзер сожраб облака, характеристике грэйна ваще никак не соответствуют.
Пиздец, облака все детали проебали.
Суп, ффмпеганы.
Написал в соседний тредю, но он еле живой. Вопрос вот >>3188278 →
Мож тут кто подскажет, программы-то смежные.
>Если dav1d обосрался, нужно попробовать aomdec.
А как смотреть на разных декодерах? Я смотрю через mpc-be и vcl, там вроде нет ни выбора декодера, ни названия того что используется.
> Да вы-ж меня обосцыте узная что я кодирую... Ладна, вот сравнение https://imgsli.com/MTE5NzA5
Спасибо
> Грэйн жутко тайлит, денойзер сожраб облака, характеристике грэйна ваще никак не соответствуют.
Тайлинг меньшая из всех проблем. Тебе надо сильнее попердолиться с кодированием грейна, или отключить синтез насовсем. Вангую, что SVT просто не может в синтез.
> А как смотреть на разных декодерах? Я смотрю через mpc-be и vcl, там вроде нет ни выбора декодера, ни названия того что используется.
> ffmpeg -с:v libaom -i 'файл' -c:v yuv4 -c:a pcm_s16le -f matroska - | mpv -
А ещё можно извлечь нужный тебе кадр
> ffmpeg -с:v libaom -ss 0:10 -i 'файл' Кадр.png
Картинки не отправились почему-то, 2 штуки webp.
Команда - ffmpeg-n5.0.1-win64-nonfree\ffmpeg.exe -i "Berserk - 02.mkv" -c:v libx265 -crf 24 -preset slower -pix_fmt yuv420p10le -bf 3 -c:a libfdk_aac -profile:a aac_he -b:a 96k "Berserk - 02.mkv - out.mkv"
Билд ffmpeg брал отсюда https://github.com/marierose147/ffmpeg_windows_exe_with_fdk_aac/releases
>Прилагаю скриншоты.
Спасибо за заботу друг ️
>>3189370
Макаке видимо хочется переплачивать за в 10 раз большего размера png-шки вместо компактных webp. Сейчас прикрепил png, надеюсь дойдут.
> -preset slower
> -bf 3
> -profile:a aac_he
> -b:a 96k
ЗАЧЕМ?
Сап. Как склеить два видео с разным соотношением сторон?
Соотношение сторон должно остаться оригинальным у обоих видео.
Никак. Оба видео должны быть одного разрешения и должны быть закодированы одним кодеком.
Потому что я - БЭТМЕН!
Но ведь от снижения числа b фреймов у тебя сжимаемость видео уменьшаеться, и приходиться тратить больше битрейта. Ты должен был поставить -bf 8.
И зачем ты зажал битрейт для аудио, ещё и SBR аключил? Наверняка твой плеер кроме HEVC также читает и Opus. Почему ты не закодировал в Opus 96?
И какие хаки были использованы что-бы закодировать это?
> Но ведь от снижения числа b фреймов у тебя сжимаемость видео уменьшаеться
В исходнике было 2 b-кадра, зажатые между другими.
>Ты должен был поставить -bf 8
Прочитал на сайте, что нужно ставить 3, всё что больше - только для анимации. Хочешь сказать, от количества b-кадров не портится качество?
>И зачем ты зажал битрейт для аудио
Если ставить vbr, то выбор есть только между 64-72 и 96-112 https://trac.ffmpeg.org/wiki/Encode/AAC . Мне же нужно от 70 до 100.
>ещё и SBR аключил?
>Почему ты не закодировал в Opus 96?
Ну, мне сказали, что opus говно, а aac-he хорош.
> Хочешь сказать, от количества b-кадров не портится качество
Ты знаешь, чем они отличаются от p фреймов?
P-кадры (англ. Predicted frames, «разностные» кадры)
могут содержать как независимо сжатые макроблоки, так и макроблоки со ссылкой на другой, предыдущий, I- или P-кадр.
B-кадры (англ. Bi-predicted frames, «двунаправленные», «обратные» кадры)
могут содержать следующие макроблоки: независимые (intra), со ссылкой на предыдущий кадр (predicted)
> Ну, мне сказали, что opus говно, а aac-he хорош.
На Opus жалуються только из-за отсутсвии блока хардварного декодирования в плеерах питающихся от батареи, а также из-за бага связанного с gappless кодированием потрековых рипов.
Ни один из этих пунктов с твоим use-case не пересекаются. Даже если ты смотришь с телефона, то экран всё равно жрёт заряда на порядок больше чем софтварное декодирование Opus аудиопотока.
Душа лежит к проприетарному, добротному, передовому. Кодируя в проприетарный кодек через свободный ffmpeg я радуюсь, как наебал систему.
>>3189744
Я подумал, ты хотел сказать, что b-кадр не портит картинку, тогда как p-кадр портит. Но b-кадр имеет все свойства p-кадра, в добавок свои свойства.
> Душа лежит к проприетарному, добротному, передовому. Кодируя в проприетарный кодек через свободный ffmpeg я радуюсь, как наебал систему.
Странный фетиш. Зачем кодировать кодеком FDK-AAC через FFMPEG, когда есть qaac? Тем более, что тебе не надо заводить wine, ты ведь и так на винде.
>Зачем кодировать кодеком FDK-AAC через FFMPEG, когда есть qaac?
qaac не умеет кодировать видео. И в принципе не справляется с 98% задач FFmpeg.
Можно даже сказать, что FFmpeg - нерушимый стандарт, а всё чего нет в ffmpeg - нинужно.
> qaac не умеет кодировать видео.
А он и не должен. Это же encoder стандарта mpeg4 aac. Его задача это взять wav pcm и дать на выходе поток данных в формате AAC, не более.
Может ты просто ниасилил пайпинг вавки из ffmpeg в qaac?
>Может ты просто ниасилил пайпинг вавки из ffmpeg в qaac?
Да, не осилил. Не приходилось заниматься пайпингом между разными программами. Подскажешь, как?
Звук в исходном файле не wav, если что.
ffmpeg -i file -map 0:a:0 -c:a pcm_f32le -f wav - | qaac --ignorelength -V 90 - -o file.m4a
av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argumentbits/s speed= 381x
size= 12kB time=00:00:00.03 bitrate=3098.1kbits/s speed=14.9x
video:0kB audio:12kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.850000%
Error closing file pipe:: Invalid argument
Conversion failed!
Пытаюсь скачать обрезанный видос такой командой. На выходе получаю ролик длиннее чем нужно. В начале проигрывается несколько секунд аудиодорожка без видео.
Дай угадаю. У тебя ERROR: CoreAudioToolbox.dll: Module not found.
Ранее этот модуль поставлялся вместе с iTunes и QuickTime. Сейчас его надо искать на варёзных сайтах.
Бамп вопросу.
>>3189924
Не знаю, как у тебя, но у меня этот батник упал. После чего я скачал QuickTime и провёл обряд чёрной магии по выдиранию оттуда CoreAudioToolbox.dll со всеми его зависимостями.
После завершения ритуала, я выполнил команду
ffmpeg -i ~/trial\ 2.wav -map 0:a:0 -c:a pcm_f32le -f wav - | wine qaac.exe --ignorelength -V 90 - -o ~/trial2.m4a
И оно работает. Как видите, изменения минимальны, и тот commandline который я запостил ранее рабочий.
Оно и с 7zip не работало. 7zip извлёк мне пустую папку QTfiles64.
>ERROR: CoreAudioToolbox.dll: Module not found
Была раньше, потом обзавёлся нужными dll-ками. Без dll никакие команды не работают, кроме списка всех команд (--help). С dll кодирование из wav на диске работает, а pipe - не работает, выдаёт ошибки:
av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argumentbits/s speed= 351x
size= 12kB time=00:00:00.03 bitrate=3098.1kbits/s speed= 3.3x
video:0kB audio:12kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.850000%
Error closing file pipe:: Invalid argument
Conversion failed!
Странно. У тебя сыплет каким-то invalid argument. Я бы запросил у тебя аргументы командной строки, но я их знаю, поскольку сам выложил. Отладить не получиться, поскольку у меня с такими аргументами всё работает. В общем, даже не знаю, что мне с этим делать.
Я неправильно добавил в переменную PATH, он не видил dll-ку.
Если к тебя всё заработало — я только рад.
вы задолбали уже. Потому что резать надо по ключевым кадрам, а не с хуева места.
>>3189379
>> -preset slower
>> -bf 3
Закодировал так:
ffmpeg-n5.0.1-win64-nonfree\ffmpeg.exe -i "Berserk - 02.mkv" -c:v libx265 -crf 24 -preset medium -pix_fmt yuv420p10le -bf 8 "Berserk - 02.mkv - out.mkv"
Файл весит 208 Мб вместо 290. При этом тени и контраст в некоторых местах проёбаны, в некоторых местах на краях объектов появляется дополнительная полоса светло-серого. Примерно такое было при использовании шейдеров в mpv.
Время кодирования существенно сократилось относительно предыдущей команды, но звук я не трогал (-acodec copy тоже не выбрал).
А вот пресет лучше не понижать без особой необходимости. Моя претензия состояла в том что ты занижал настройки выбранного пресета. У пресета slow их было 4. У slower наверно даже 8, но это мне документацию смотреть надо.
> -acodec copy
Оставляй так всегда, за исключением lossless дорожек, или дорожек с битрейтом 640k.
>У пресета slow их было 4. У slower наверно даже 8
Ты про b-frames (-bf)?
А что на счёт цветового пространства? Я как-то раз делал скриншоты в mpv, кодировал в lossless webp. И каким-то образом смог поменять цветовое пространство у скриншота, может быть сменив цветовое пространство видео, хз. Так вот скриншоты lossless webp с разным цветовым пространством весили 1.41 и 1.70 Мб, с чего бы? Ещё в консоли было написано жёлтым цветом: "ffmpeg/libwebp: рекомендуем использовать какое-то другое цветовое пространство для lossless".
>Оставляй так всегда, за исключением lossless дорожек, или дорожек с битрейтом 640k
В исходнике какой-то кинематографический кодек звука, звуковая дорожка весит 260 Мб - почти как сжатый mkv видео+звук+сабы.
Звук кодировать буду отдельно через qaac. В режиме cvbr или tvbr - не определился. cvbr хуже жмёт, но не портит качество специфической музыки (с резкими перепадами битрейта до очень низких значений). Надо будет поискать порог прозрачности для qaac.
Есть ещё какие-нибудь оптимизации и хитрости? Может быть, сократить количество ключевых кадров до 1 раз в 10 секунд, но чтобы в плеере перемотка до ключевого кадра (точная перемотка) происходила моментально.
> сократить количество ключевых кадров до 1 раз в 10 секунд, но чтобы в плеере перемотка до ключевого кадра (точная перемотка) происходила моментально.
Нет, так не получиться. Точность быстрой перемотки по ключевым кадрам прямо зависит от их количества. К тому же у x265 дефолтом стоит gop size 240 или 250, что примерно соответствует 10 секундам у подавляющего большинства фильмов и сериалов.
>К тому же у x265 дефолтом стоит gop size 240 или 250, что примерно соответствует 10 секундам у подавляющего большинства фильмов и сериалов.
В сорсе моих видео ключевой кадр стоял каждую секунду (может чаще, в плеере я могу перематывать с точностью до секунды, без точного поиска), и после кодирования я всё ещё могу перематывать с точностью до секунды. Так же кодирование сохранило структуру gop - в закодированном видео было 2 b-кадра, пока я вручную не выставил -bf 8.
Можно без конвертирования вставить отрывок в контейнер mp4
Спасибо!
Тем же ffmpeg? Сурс - аудио, аутпут - mp4 и какое-нить мелкое разрешение, так?
Попробовал, всё отлично. Нафиг костыли, когда такой отличный инструмент есть.
Пасип.
Ну так запости и всё. Правда, открыть будет трудно, так как изображения нет. Либо как сам сказал вместе с картинкой сделай, если музыка например.
UPD. Макака на новом движке походу сломала импорт mp3. Пишет тип файла не поддерживается. Раньше даже тупо mp3 без контейнера mp4 лился. Песда.
Ну что сказать. Качайте дети флаки чтобы потом сжать их в 64kbps чтобы просто залить на двачи.
Про детей это я так, образно. Не воспринимайте на личный счёт.
Я думаю прогнать это через hevc_nvenc, он за разумное время конвертирует некоторые видео уменьшая в десять раз без какой-либо заметной разницы даже если кадры отдельные рассматривать. Там есть режим аналогичные crf-режиму из h264, или "-crf 30 -b:v 0" из vp9?
"-rc constqp -qp 20" - это то что нужно? Почему для "-rc vbr -cq 23" значение cq игнорируется и файлы получаются одинаковые? Может быть там есть какое-то особое заклинание, по типу -b:v 0 из vp9, без которого не работает?
Нет, qp это неоптимальный режим. Nvenc поддерживает crf кое как.
И вообще запомни, аппаратное кодирование всегда хуже процессора
В nvenc вообще нет crf по сути.
>И вообще запомни, аппаратное кодирование всегда хуже процессора
Не хуже, на +60k разницы нет.
> на +60k разницы нет.
погоди, ЧТО?
Этот битрейт считается низким даже по меркам аудио битрейтов. А ты мне про видео…
Или ты имел в виду 60Mbps? А зачем тогда собственно перекодировать? Не проще ли оригинал оставить как есть.
Вот 3 мегабита это ещё нормальный битрейт. 10 мегабит ещё куда не шло, если у тебя конечно не 4K видео.
И вообще, если хочешь что-то сжать, то только софтварное кодирование на медленных пресетах. Иначе ты будешь бездарно просирать и место, и время на кодирование.
Реалтаймовая параша годиться либо для сохранения избыточной информации для дальнейшего транскода, либо чтобы высирать мыльную заблоченную картинку на стриминговые сервисы. Вот как раз для сохранения избыточности и используют битрейты вроде 20M, те-же 60М, 100М, в общем сколько через I/O диска пролезет, столько и пишут.
>Или ты имел в виду 60Mbps
yes. На самом деле даже намного меньшим.
Ты чё в ффмпеготреде забыл с такими битрейтами? Мы тут пытаемся вселенную сжать обратно в сингулярность, а не срать избыточностью.
Значит пора.
Дополнительных параметров пока не придумал, буду жать почти дефолтами, передам SVT'шке keyint=10s наверн как везде советуют.
Не могу выбрать crf, в интернетах советуют ренж 22-28, я выбираю всего из 22, 23, 24. Хз, небольшие семплы пожал, вроде бы все 3 норм, но вдруг тут кто экспериментировал шире. Понятно, что и как бы жаба душит, но и уничтожать данные не хочется
webp лучше сжимает, чем jpeg, проталкивается гуглом - вечно живой. Сейчас веб перекатывается на webp, поттягиваются с поддержкой даже отсталые вьюверы. Жми в webp и точка.
PNG для лослесс конечно
Полная хрень и чушь. Пережимать лосси джипег это надо быть крайне плохим, лосслесс вебп весит меньше пнг, потому пнг выгодно перегонять в вебп.
Нашел вот два способа:
> -vf "minterpolate=fps=60:mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1"
> -filter:v tblend -r 60
И все они отвратительно работают: картинка дерганная, движение рвется. Попробовал в премьере выбрать optical flow - гораздо лучше результат
Webp и для лосслесс тоже.
>Пережимать лосси джипег это надо быть крайне плохим
Чо бля? Пережимал крайне малопотерьный жипег в 95 квалити вебп, наэкономил дохуя места.
> Пережимал
Визуально оценивать пережатие архива на 100к изображений я рот того ебал, а сжатие без потерь потерянного жипега приведёт к значительному росту размером.
Потому затея и хуйня, в большинстве случаев, если ты какой-то фотограф, фотографирующий в "малопотёртом жипеге", то тебе может и норм, ты знаешь, что размер гарантированно уменьшится, потому что в жипеге присутствует избыточность, ну либо если тебе пережать на поебать как, то можно и вебп, я често говоря не пробовал пережать шакалов жипега в шакалов вебм и сравнить сколько кб я от этого выиграю.
>>3192840
>>3192841
>Пережимать лосси джипег
Зачем пережимать лосси джипег в webp, если можно пережать в jxl без потерь?
Хотя бы потому что я первый раз о таком услышал? В джипег и пнг с нами десятки лет, вебп тоже не отстаёт. В 2007 ты бы наверное сказал зачем пережимать джипег в %имя_кодека%, если есть джпипег2000, тогда тоже писали, что
> Он призван превзойти существующие растровые форматы и, таким образом, стать их универсальной заменой
Но кто о нём сейчас помнит.
jxl уже внедряется везде где только можно, в браузеры поддержку уже давно завезли через флаги в скрытых настройках, во всех актуальных просмотрщиках - тоже, в сабже - тоже. Что тебе еще надо-то блять?
А можна мне готовую строчку попробовать?
Какую строчку?
ffmpeg -i in.jpg -effort 9 out.jxl
> но и уничтожать данные не хочется
А может не надо пересжимать, а оставить как есть. Любое lossy кодирование ведёт к потерям данных.
В качестве lossless форматов один из лучших.
Также этот формат лучше джипега если этот жипег это yuv 4:2:0 limited. Ничего другого кроме (yuv 4:2:0 limited) lossy webp кодировать не умеет.
Область применения: кодирование thumbnails для веба. В основном для веба он и нужен. Но тенденция на yuv 4:4:4 его вытесняет и оттуда. Youtube, Netflix переходят на jpeg 4:4:4, потому что он поддерживает 4:4:4, даже для thumbnails.
Если тебе нужно пережать PNG в lossy, советую обратить внимание на форматы JPEG-XL, HEIF, AVIF.
> Что тебе еще надо-то блять?
Вот когда картинки в браузер будут грузиться без настройки about:config, вот тогда и поговорим.
Зачем, когда уже всё есть в x265, где fullhd серия 22 минуты с экшоном весит всего 250-300мб. HD вообще 150-200.
Если тебе именно интерполяция кадров нужна, то гугли Flowframes и RIFE .
Зачем ты спалил конченный пердольный мусор нормальному человеку?
А лично ТЕБЕ это будет как-то мешать использовать его?
Надобится в интернет загрузить и получать ошибку "не поддерживаемый формат файла"? Так себе удовольствие. Я же не для себя эти картинки собираю!
Макака даже до сих пор не приделал webp для постинга. Сам браузер-то показывает.
Браузер так-то и avif показывает, но загрузить его некуда от слова совсем.
Вопрос насколько, все просто. Тут нужны экспериментаторы.
>>3192914
Очевидно, большая часть пыляющихся тайтлов тухнет в h265
> если можно пережать в jxl без потерь
Пережать можно, а потом просмотреть (с тюмбнейлами) - не факт.
>>3192841
> я често говоря не пробовал пережать шакалов жипега в шакалов вебм
А вот я пробовал, и это никакие не фотки, а картинки с буры, так мне еще похуй, если там микрошакалы добавятся еще от вебпа.
>просмотреть (с тюмбнейлами) - не факт
Чел твой xnview/irfanview/что там еще есть?
Потому-что у васянов-сжимателей полная жопа с ключевыми кадрами. При обычной перемотке на 1 секунду плеер мотает на 10. А я люблю отматывать на одну секунду назад, не тратя несколько секунд на точный поиск. Сейчас начал сжимать аниме - 25-минутные full hd серии с ключевым кадром каждую секунду сжимаются из 6150 Мб в 250-280 Мб, этого более чем достаточно. У васянов и файлы больше весят, одна серия - 1 или 3 гига. И я сомневаюсь, что качество в их раздачах не хуже чем в оригинале (у меня не хуже, только шум плёнки полностью исчез, можно улучшением считать).
> При обычной перемотке на 1 секунду плеер мотает на 10. А я люблю отматывать на одну секунду назад, не тратя несколько секунд на точный поиск.
> передам SVT'шке keyint=10s наверн как везде советуют.
Если ты это сделаешь, то ты получишь то-же самое что и в васянским рипах.
Если тебе нужна быстрая перемотка по одной секунде, тогда ставь gop size равным одной секунде. Только потом не жалуйся что ключевые кадры раздули тебе битрейт. И ещё: для компенсации этого безобразия можешь попробовать открыть GOP. Это позволит кадрам из одной группы ссылаться на кадры из соседней группы.
Гатаридебил с тамймингами панцушотов не иначе. Скринов наделай, лол.
Заходишь на няшу, ищещь и качаешь. Хоть каплю известные тайтлы и выше 100% есть.
>>3193041
>При обычной перемотке на 1 секунду плеер мотает на 10. А я люблю отматывать на одну секунду назад, не тратя несколько секунд на точный поиск.
Ну так поставь перемотку не по ключевым. Отмазка шиза конечно, так и напиши, что тебе хочется попердолиться и покодировать от безделия.
>У васянов и файлы больше весят, одна серия - 1 или 3 гига.
Я буквально в прошлом написал сколько весят.
>И я сомневаюсь, что качество в их раздачах не хуже чем в оригинале
Уж получше чем у пердолика, потому что люди этим годами занимаются, плюс используют крутые штуки и фильтры в vapoursyth. По типу тех же beatriceraws.
На линухе поддержка тюмбнейлов в webp требует установки доп пакета на большинстве дистров.
А view всякие это не тюмбы энивэй, я хз что за пися на винде за них отвечает, качал раньше такую, уже не помню - страшная штука, Икарос что-то там
Я бы хотел сказать ОК, но ты мне предлагаешь сабы под это дело отдельно добывать? Я не помню русабов на няше
Я ничего особого в своей каллекции не храню, просто если посезонно выходит, то можно пересмотреть. Это все следует из того, что я качаю и смотрю оффлайн.
> Palemoon
твое ебло на пике?
Отлично выгляжу, скажи
SVT-AV1 еще слишком сырой, scd не работает от слова совсем. Без этого жать в принципе не вижу смысла.
Note that not inserting a key frame at scene changes is not considered a bug
nor missing feature by the SVT-AV1 team. AV1 is sufficiently flexible that when
a scene change is detected, the encoder automatically relies less on temporally
neighboring frames, which allows it to adapt to scene changes without affecting
the GOP structure (frequency of key frames).
Круто, но в это трудно поверить. От того, что на смену сцену приходится не I-фрейм, а относительный, даже если AV1 понял, что связи мало, что-то должно страдать. Может быть, скорость декода таких тяжелых ссылочных фреймов.
Твоя паста обоссывается в одном из issue в той же репе каким-то анимечником, ищи, читай.
Да я знаю, но кодировать неделю времени 100 гб своего видео чтобы оно занимало 50 не хочется, а в h265 через карточку можно перегнать за час или два.
Только из-за того что кодек другой, на некоторых видео (особенно с листвой) то когда я конвертирую 40 мб h264 в 60 мб h265 - то куча деталей теряется, так что даже без паузы и остановки видео видно - поэтому я уже почти отказался от этой идеи и только ночные и вечерние видео пережал, которые раз в десять уменьшаются без потери качества.
Вот если бы был h264++, который использует те же преобразования и не добавляет новые характерные для другого кодека артефакты...
>>3192842
Например, если вот эта штука работает, и именно jpg никак не портит сильнее, вот что-то такое. Буду тестировать, а программу для превью можно и самому сделать для виндоуса.
> Да я знаю, но кодировать неделю времени 100 гб своего видео чтобы оно занимало 50 не хочется, а в h265 через карточку можно перегнать за час или два.
Значит так. Сперва ты говоришь разрешение и битрейт своих видео, а мы как нибудь прикинем итоговый размер всей этой кучи на выходе.
> только ночные и вечерние видео пережал, которые раз в десять уменьшаются без потери качества.
надеюсь ты оставил исходники, так?
с рутрекера скачай.
>Сперва ты говоришь разрешение и битрейт своих видео
Случайное. И ещё там бывает статичная картинка, а бывает подвижное вращение в лису, где всё цветное, да ещё в 4к.
Да и какое это имеет значение, если после перекодирования crf-режим из h264 (или его аналог в h265, если он всё-таки работает) сам возьмёт сколько ему нужно битрейта чтобы с погрешностью не выше заданной передать любые фпс, разрешения и прочее?
>надеюсь ты оставил исходники, так?
Пока да.
Лесу. С деревьями.
Хотя лиса тоже есть на коротком видео, кстати.
Пора перекодировать в ав1, харкач, кажется, его теперь поддерживает.
А говорил что у тебя CBR во всех исходниках.
Ты мне так и не ответил, что там у тебя с разрешением.
Двачую. VP9 слишком шакальный.
Если бы можно было ещё звук улучшить, было бы вообще замечательно.
Я уже скачал, вместе с видео, типа сабы и видео синхронны воооот.
куда лучше opus
Интересно в какой-нибудь дистр линуха завозят ffmpeg с rav1e? Выглядит вкусно, пусть и на расте.
Да показывает, превью. Можно на av1 переходить.
> куда лучше opus
Говорят вышел USAC, он же xHE-AAC. Специально разрабатывался для низких битрейтов. Но декодировать его можно только собственноручно собранным ffmpeg с libfdk-aac, а иначе ну вообще никак.
Я вот тоже считаю, что пока в ffmpeg не добавят нативный декодер этого кодека, в него нельзя ничего кодировать. А его могут так никогда и не добавить, ибо закрытость и патенты.
CBR в каждом отдельном файле, но иногда я вручную переставлял битрейт на другой, если видел что сцена простая или сложная.
Вот как-то так из того что тут, и на внешнем диске ещё куча которых 3840х2160, но мобилка их изначально в h265 писала - не уверен что есть много смысла их трогать.
пасеба, в федоре небось и пакеты самые свежайшие
> для низких битрейтов
А что вообще принято считать низкими битрейтами в народе? Для меня это 16-32к, уровень voip
Ну и зачем тебе перекодировать эти файлы, тем более в 60M?
Я так понял тебе нужен near lossless, поэтому пережимать 1080p 10M смысла нет вообще. А вот файлы 1080p 28M-29M можно сжать посильнее. Релизёры с торрентов уже давно этим занимаются, можешь поспрашивать у них, как надо жать H264. Но самый минимум, как я понял, это x264, -preset veryslow -crf 18.
Пережал для пробы исходник MJPEG 720p 30М в crf18, получилось 12М, недалеко от средних битрейтов BDRip-ов, но там такие битрейты для 1080p, так что потенциал для более сильного сжатия остаётся.
Ну тут по всякому. По меркам MP3 это всё что ниже 128k. По меркам Opus это от 64k и ниже.
Занимают слишком много места. У меня на системном диске свободно 20 гб из 931, и четыре внешних жёстких диска по терабайту забитые полностью. И мне не нравится cbr режим, когда в статичном сегменте видео видно каждый листик, а на время вращения камерой всё сыпется квадратами. Вот бы мобилка сразу в cq режиме записывала забирая сколько ей нужно битрейта... Вопрос религии в общем.
>А вот файлы 1080p 28M-29M можно сжать посильнее.
Это же очень сильно от сцены зависит. Ночной мыльный пейзаж где только силуэты можно хоть до 2кк сжать, а вот листва в лесу даже сжатая до 20кк сильно хуже выглядит и там 20кк сильно не хватает. Я crf 22 ставлю, а иногда и 25 - но на процессоре 4к видео я отказываю переконвертировать даже на veryfast-h264, не говоря уж про процессорный h265.
> webm поддерживает av1
Да, но нужен свежий ffmpeg, чтобы он умел паковать ав1 в цуиь
> Что лучше aom или svt
Хуже аом ничего нет, выбирай между свт и rav1e
>Хуже аом ничего нет, выбирай между свт и rav1e
Да почему хуже-то? Да, реалтайм пресетов нет, да, иногда может чуть дольше кодировать. Но зато поддерживает все фичи и в теории может обеспечить самую лучшую компрессию.
Есть какое-то нормальное сравнение, а не просто пуки в воздух?
Есть, aom топ.
https://www.reddit.com/r/AV1/comments/f1h2u1/aom_vs_rav1e_vs_svtav1_vs_x265_vs_vp9_vs_svtvp9/
>3 года назад
А поновее нет ничего?
Он нагружает максимум одно ядро и особо не развивается. Svt не хуже но намного быстрее
Ебанулся? Минимально смотрибельные 4000-5000 Ютуб берёт, и то мыло. Только если медленные пресеты
Для vp9 рекомендуется 1800 битрейт судя по гайду, для av1 должно быть ещё меньше.
https://developers.google.com/media/vp9/settings/vod
>Он нагружает максимум одно ядро
Чел твой тайлинг?
>Svt не хуже но намного быстрее
А нормальное сравнение-то будет, а не пуки в воздух?
> иногда может чуть дольше кодировать
Это на каких процессорах так? У меня svt кодирует в >100 раз быстрее, aom какбэ вообще не кодирует честно говоря.
>>3193493
> А нормальное сравнение-то будет, а не пуки в воздух?
Можешь сравнивать, разрешаю
>У меня svt кодирует в >100 раз быстрее
Так он и кодирует мыльное говнецо на таких скоростях как бы, тут даже сравнивать ничего не нужно.
А давно макака прикрутил превью к ав1? Буквально несколько месяцев назад проверял, не было.
Да на прошлой неделе буквально.
> Так он и кодирует мыльное говнецо на таких скоростях как бы, тут даже сравнивать ничего не нужно.
А нормальное сравнение-то будет, а не пуки в воздух?
Можешь сравнивать, разрешаю.
Так он и кодирует хорошо на таких скоростях как бы, в отличии от мыльного говнеца libaom, тут даже сравнивать ничего не нужно.
А, это с новым движком ввели, понял.
Да-да, аом говно, ты подебил, успокойся только.
-c:v libaom-av1 -b:v 0 -crf 35 -g 12312 (возможно нужно дописать -strict 2 или что-то такое, там загуглишь ошибку).
Если тебе покажется что он не кодирует, так и должно быть, на не таком плохом процессоре один кадр 1920х1080 обрабатываться может даже минуту.
Или -c:v libsvtav1 -b:v 0 -preset 10 -crf 35, если найдёшь или сделаешь билд с этим svt.
Я сам только настроил, и немного пугает что libvpx-vp9 работает раз в десять медленнее чем libsvtav1
>-c:v libaom-av1 -b:v 0 -crf 35 -g 12312
Где твой -cpu-used или -speed?
Я их не использую. Кодек и так не реалтаймовый (по крайне мере первый), потому я предполагаю что он и так обеспечивает наилучшее соотношения размера/качества без учёта времени кодирования. Вот в реалтаймовом это смысл имеет, где есть акцент на скорость кодирования.
>так и должно быть
Нет, так не должно быть, на моем проце один 1920х1080 кадр с самым быстрым пресетом aom кодируется примерно в два раза быстрее самого медленного пресета vp9
>-g 12312
Ты это зачем сюда вписал, дебс, чтобы на аом насрать?
Случайно. А что это команда делает?
Если я помню, она про ключевые файлы, а у меня видео на 15 секунд и там не нужны ключевые кадры кроме первого.
Ты нахуя людям чё-то советуешь, если сам даже базу не знаешь, долбоёб?
> libvpx-vp9 работает раз в десять медленнее
Сука, что гугловский aomenc работает медленно, что гугловский libvpx-vp9.
Я уверен, что гугл выкладывает энкодеры - лишь бы качественно делали, потому что им сжатие matters, а для скорости работы они для своей инфраструктуры пилят патчи, на остальных им похуй.
Вот интел SVT-AV1 изначально делала, чтобы быстро работало на свежих интелах, AVX512 вся хуйня. Но попен сорц подебил и теперь там оптимизации вплоть до каменного века (ссе2).
rav1e пилилися как я понимаю лишь бы на расте что написать, но у них неплохо получилось относительно avg растоман
Могли бы запостить раньше меня. Никто не советовал анону как av1 получить - я посоветовал. Сижу сейчас подбираю другие кодеки, чтобы такой же размер получить и сравнить.
Я тоже буду признателен, если посоветуете команду, но без пресетов хоть сколько бы медленнее стандартного aom.
>>3193525
>с самым быстрым пресетом aom кодируется примерно в два раза быстрее самого медленного пресета vp9
А по качеству при этом проигрывает, и то же самое у меня получилось с самым быстрым пресетом vp9, что при равном времени кодирования даже h264 сжимает лучше vp9, которые весь сыпет артефактами чтобы хоть как-то успеть (там, кстати, пришлось и -cpu-used прописывать).
>rav1e пилилися как я понимаю лишь бы на расте что написать
ИЧСХ это не на расте написано, а на ассемблере, а на расте так, вставки.
>А по качеству при этом проигрывает
В том-то и дело чел, что выигрывает.
Точно? Ну, я тестил года два назад, кодировал почти два дня разные отрывки разношёрстного видео, и получилось что кодек полегче, который и не замахивается на что-то сложное при низком времени кодирования справляется, так как успевает основные свои фичи реализовать, а тяжёлый кодек лишь по верхам нахватывается.
Прикольно вышло да, в среднем получился С++ как раз
Это попугаи. Для хорошего качества должен получиться удав.
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
>удав
Удав?
Vmaf до 100, лучше больше
Хотя он говно, сравнивай на глаз
ffmpeg -hide_banner -i syava.webm -pass 1 -c:v libaom-av1 -cpu-used 8 -strict experimental -b:v 99.0k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -an -sn -y -f webm nul
ffmpeg -hide_banner -i syava.webm -pass 2 -c:v libaom-av1 -cpu-used 8 -strict experimental -b:v 99.0k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -ac 2 -c:a libopus -b:a 96.0k -sn -y -f webm syava-av1-aom.webm
Затрачено 02:27.5
ffmpeg -hide_banner -i syava.webm -pass 1 -c:v libvpx-vp9 -speed 4 -tile-columns 6 -frame-parallel 0 -row-mt 1 -b:v 99.0k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -an -sn -y -f webm nul
ffmpeg -hide_banner -i syava.webm -pass 2 -c:v libvpx-vp9 -speed 0 -tile-columns 6 -frame-parallel 0 -row-mt 1 -b:v 99.0k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -ac 2 -c:a libopus -b:a 96.0k -sn -y -f webm syava-vp9.webm
Затрачено 04:19.6
ffmpeg -hide_banner -i syava.webm -pass 1 -c:v libsvtav1 -preset 10 -tile_columns 4 -b:v 99.0k -threads 16 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -an -sn -y -f webm nul
ffmpeg -hide_banner -i syava.webm -pass 2 -c:v libsvtav1 -preset 10 -tile_columns 4 -b:v 99.0k -threads 16 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -ac 2 -c:a libopus -b:a 96.0k -sn -y -f webm syava-av1-svt.webm
Затрачено 00:27.3
ffmpeg -hide_banner -i syava.webm -pass 1 -c:v libsvtav1 -preset 5 -tile_columns 4 -b:v 99.0k -threads 16 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -an -sn -y -f webm nul
ffmpeg -hide_banner -i syava.webm -pass 2 -c:v libsvtav1 -preset 5 -tile_columns 4 -b:v 99.0k -threads 16 -g 128 -pix_fmt yuv420p -vf crop=1472:1072:224:4,scale=-2:576 -ac 2 -c:a libopus -b:a 96.0k -sn -y -f webm syava-av1-svt-5.webm
Затрачено 04:13.2
Шах и мат, светаёбы. Ваш кал не нужен ни для чего, кроме как для реалтайма с тоннами битрейта.
Смысл было кодировать это говно. Если оригинал мыльное старое говно. Тупо ради прикола? Ну тупой, не?
Оно перезалито было с качеством чуть получше.
https://www.youtube.com/watch?v=MiXRkmamHu0
А что еще кодировать чел?
То, от чего не вытекают глаза и не вянут уши в процессе сравнения.
Не благодари, можешь еще и аудио потестить
Ебать тут шакалов, даже у сявы в оригинале меньше.
Такое говно качество. Даже результат прогнанный через топаз раз в миллион будет, это еще помимо артефактов с ютуба. Точнее не даже, в раз в 500 пизже. Это так вообще такое же мыльное говно с артефактами древней камеры и полосками от интерлейса.
>>3193612
Сурс говниме или лайввидео 4к и 80000к битрейта.
Выбери сам, большой мальчик уже.
>Сурс говниме
На диске только вебки есть, разве такое пойдет для суперпуперкачественного энкода? Не качать же для хуйла с двачей блюреи.
>На диске только вебки есть, разве такое пойдет для суперпуперкачественного энкода?
Так скачай.
>Не качать же для хуйла с двачей блюреи.
Нахуй сходи тогда, уебан тупорылый.
Ладно чел, не гори.
А если ты принесешь 4К, и у анона нет такого моника, то тоже несчитово, потому что за даунскейл отвечают несовершенные алгоритмы плеера
> обоссывается в одном из issue в той же репе каким-то анимечником
Буквально https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1929 про превращение видеоцитаты из второго сезона Oregairu в говно на протяжении четырёх кадров, предшествующих ключевому кадру, причём так происходит два раза за одну видеоцитату.
> для компенсации этого безобразия можешь попробовать открыть GOP. Это позволит кадрам из одной группы ссылаться на кадры из соседней группы.
Это не позволит видеозаписи нормально проматываться.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1548
https://bugs.chromium.org/p/aomedia/issues/detail?id=2862
Нужно ли использовать, когда, зачем, какие профиты, улучшает ли качество моих шебм?
Спасибо.
mediainfo неси, так непонятно че несешь.
Там все сложна и очень много букоф конечно, но максимально доходчивый аргумент - это то, что энкодер, умеющий в SCD, может закодировать и так, и так, а потом сравнить эффективность. А не умеющий энкодер не имеет выбора. Не вижу в первом случае замедления энкода на >5%.
Потому что 5% не по скорости, а по росту объёма файла при включённом scd, каким рост был до его мартовского всеобщего отключения scd.
Просто склей в нужном порядке..
А, всё, нашел.
https://www.youtube.com/watch?v=Obf3j1bALY8
Кстати, может подскажите как лучше сжимать, если у меня задача, максимально пожать&быстро&при минимальном читабельном качестве.
Просто в гугле все пишут, с сохранением качества, а мне, ну лишь бы что-то разобрать можно было.
Пока так для себя поставил методом тыка.
Раз старая кухня их не устраивала, то по-новому scd нескоро включат.
-vcodec hevc_nvenc -rc constqp -qp 28
28 понижаешь для более хорошего качества, понижаешь для более плохого. 1920х1080 кодируется в реальном времени на средней карточке.
Или -vcodec h264_nvenc -rc constqp -qp 28, тут вообще скорость будет х5.
>Ребят, если я не могу в консольку
Напиши батник как на видео, и просто мышкой на него перетаскивай. Сразу несколько файлов можно, папки нельзя.
И вот два кадра для сравнения. Оригинал и -qp 32, если ты прям настолько что лишь бы читабельно было - понижай сразу до 50, это будет как третий кадр, но видео всего 6 мб занимает вместо 200, и это без снижения родных 60 фпс.
Я даже скопирую, но вдруг пройдёт не попортив символы из-за разметки.
:st
if %1=="" exit
echo %1
echo "%~dpn1.mp4"
ffmpeg -i %1 -vcodec h264_nvenc -rc constqp -qp 50 -c:a libvorbis -b:a 64k "%~dpn1_h264nv-qp32_ab64.mp4"
shift
goto st
Анончик, спасибо, классный батник получился.
Но я попытался модифицировать код, можешь пожалуйста поправить, что не так?:
1) я конвертирую видео технические всякие, и там в основном статичная картинка с текстом, поэтому 12 фпс с головой наверно хватит. Я вот нагуглил что надо поставить -r Nfps, но это не сработало.
2) еще вот если видео больше 720 то уменьшить разрешение до 720, а если меньше равно 720 то не трогать.
Напр. 1080 -> 720, a 480 -> 480, 720 ->720
3) Вот это получилось, я вроде читал в факе каком-то что опус норм(размер/качество), поставил его и битрейт повыше. Звук пусть получше будет, там много говорят.
Если запись была в 30 фпс, то лучше ставь кратное, 15-10-7.5-6-5, 12 только если запись была в 24, 60 или ещё что-то такое. Впрочем, это не так важно.
> Звук пусть получше будет, там много говорят.
Для разборчивого разговора с узнаваемыми голосами хватит 24k опуса.
>в основном статичная картинка с текстом
ffmpeg -i %1 -vcodec h264_nvenc -rc constqp -qp 40 -vf "mpdecimate,fps=15,scale=-2:min(in_h\,720)" -c:a libopus -b:a 24k "%~dpn1_h264nv-qp40_opus24.mp4"
1. mpdecimate - если два кадра совпадают, он не кодирует новый. Идеально, если у тебя статичная картинка. Не знаю работает ли с h264_nvenc, по идее constqp режим уже это сделает.
2. scale=-2 - потому что h264 не поддерживает нечётное разрешение видео, нужно с округлением до 2.
3. Пробовал заменить h264_nvenc на hevc_nvenc? Я что-то проверил, время кодирования не отличается. А качество повыше, пожалуй, как бы мне не хотелось это признавать.
Привет, спасибо! Работает супер, быстро и пожало хорошо, меньше размер чем в handbrake.
Только выбило какое то предупреждение.Пик1
Хевк я не пробовал и не пытался, пушто у меня старая нвидиа и не поддерживает его.
(Ну так как они аппаратные кодеки, может карточка и тратит на них одинаковые ресурсы? Поэтому время у тебя одно. Ну а хевк более совершенный, вот качество и выше. (ну это я так, предположил, я то не разбираюсь сильно).
Кстати, если интересно, пожатые видео с текстом, потом удобно смотреть, применяя шейдеры аниме4к( :D). Становится норм резкость. Конфиг для мпв взял отсюда https://2ch.life/s/arch/2022-06-06/res/3132262.html#3132937
>меньше размер чем в handbrake.
У тебя там тот же кодировщик указан, и по идее соотношение размера-качества такое же должно быть. Там ещё пресеты есть всякие на самом деле, но я не особо заметил разницу...
>у меня старая нвидиа и не поддерживает его.
Точно? Это вопрос больше программный, после определённого года карточки предназначены (более-менее) для произвольных расчётов, и даже кодеки которые появятся через много лет можно будет на них кодировать.
Попробовал бы ну, всего 3 символа поменять, и потом подобрать новую цифру qp.
А что не в полном экране, дача?
Я просто нажимаю ctrl+win+s, а вот print-screen на ноутбучной клавиатуре только через fn есть, всегда так делаю.
Дача, но там 200 кб по сравнению с jpg с травой выше всё-равно же фигня...
Точно, gt640. Поменял буквы(hevc_nvenc) - просто нулевой файл создаёт. если оставить только "hevc" то кодирует, но долго.
> Точно? Это вопрос больше программный, после определённого года карточки предназначены (более-менее) для произвольных расчётов, и даже кодеки которые появятся через много лет можно будет на них кодировать.
Либо ты ошибаешься, либо я чего-то не знаю. Кодирование на карточке не зря называют аппаратным, медиадвижок это asic.
>>3195208
Долго, потому что программно, на процессоре, то есть это другое. Хотя обычно пишут libx265, насколько я помню (не кодирую в него), но можно и так.
Ещё почитай на вики про аппаратные возможности GT 640. Это поколение Kepler, чип GK107.
https://ru.wikipedia.org/wiki/Nvidia_NVENC
https://en.wikipedia.org/wiki/Nvidia_NVENC
https://ru.wikipedia.org/wiki/Nvidia_NVDEC
https://en.wikipedia.org/wiki/Nvidia_NVDEC
вау, я даже не знал, что такое древнее говно может в nvenc. Думал только с 900 серии и 750ti есть.
Почему фуфмпег убивает битрейт звука при мерже?
ffmpeg -stream_loop -1 -i input.mp4 -i input.mp3 -shortest -qscale:v 1 -qscale:a 1 -map 0:v:0 -map 1:a:0 -y out.mp4
Если я делаю -qscale:a 0,1 или 2 то битрейт звука 130 с искажениями, если -qscale:a 3-4 или выше то битрейт 350 и все равно есть мелкие искажения хотя оригинальный битрейт 192. Что за хуйня?
А ты думал битрейта побольше дашь, чем в оригинала и он тебе флак сделает? Не сделает. Но прична может быть не только в этом, выведи полную статистику сообщений ффмпег и посмотри не делает ли он каких-то дополнительных преобразований к твоему аудио, которые могут повлиять на искажения.
А как это узнать? Я немного напиздел, на 2 битрейт 250
ffmpeg -stream_loop -1 -i input.mp4 -i input.mp3 -shortest -qscale:v 2 -qscale:a 2 -map 0:v:0 -map 1:a:0 -y out.mp4
ffmpeg version 2022-08-18-git-48be6616d0-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 33.101 / 57. 33.101
libavcodec 59. 42.101 / 59. 42.101
libavformat 59. 30.100 / 59. 30.100
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 46.103 / 8. 46.103
libswscale 6. 8.102 / 6. 8.102
libswresample 4. 8.100 / 4. 8.100
libpostproc 56. 7.100 / 56. 7.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41iso4
creation_time : 2022-08-03T18:09:13.000000Z
Duration: 00:00:12.01, start: 0.000000, bitrate: 654 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 720x850, 515 kb/s, 60 fps, 60 tbr, 60k tbn (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Eyes v2.9.0
vendor_id : [0][0][0][0]
encoder : AVC Coding
Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Ears v2.9.0
vendor_id : [0][0][0][0]
Input #1, mp3, from 'input.mp3':
Metadata:
encoder : Lavf59.30.100
Duration: 00:00:41.74, start: 0.023021, bitrate: 128 kb/s
Stream #1:0: Audio: mp3, 48000 Hz, stereo, fltp, 128 kb/s
Metadata:
encoder : Lavc59.42
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Stream #1:0 -> #0:1 (mp3 (mp3float) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 000001f81eb0c300] -qscale is ignored, -crf is recommended.
[libx264 @ 000001f81eb0c300] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 000001f81eb0c300] profile High, level 3.2, 4:2:0, 8-bit
[libx264 @ 000001f81eb0c300] 264 - core 164 r3095 baee400 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'out.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41iso4
encoder : Lavf59.30.100
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 720x850, q=2-31, 60 fps, 15360 tbn (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Eyes v2.9.0
vendor_id : [0][0][0][0]
encoder : Lavc59.42.101 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
Metadata:
encoder : Lavc59.42.101 aac
frame= 2924 fps=540 q=-1.0 Lsize= 6536kB time=00:00:48.68 bitrate=1099.8kbits/s speed=8.99x
video:5013kB audio:1454kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.061763%
[libx264 @ 000001f81eb0c300] frame I:12 Avg QP:19.49 size: 38835
[libx264 @ 000001f81eb0c300] frame P:737 Avg QP:24.94 size: 4095
[libx264 @ 000001f81eb0c300] frame B:2175 Avg QP:26.28 size: 758
[libx264 @ 000001f81eb0c300] consecutive B-frames: 0.6% 0.3% 1.0% 98.1%
[libx264 @ 000001f81eb0c300] mb I I16..4: 17.1% 51.6% 31.4%
[libx264 @ 000001f81eb0c300] mb P I16..4: 0.4% 0.9% 0.1% P16..4: 24.2% 8.5% 3.9% 0.0% 0.0% skip:62.0%
[libx264 @ 000001f81eb0c300] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 22.5% 1.1% 0.1% direct: 0.0% skip:76.3% L0:48.8% L1:49.1% BI: 2.1%
[libx264 @ 000001f81eb0c300] 8x8 transform intra:57.1% inter:59.2%
[libx264 @ 000001f81eb0c300] coded y,uvDC,uvAC intra: 25.9% 37.6% 26.8% inter: 1.6% 1.9% 0.1%
[libx264 @ 000001f81eb0c300] i16 v,h,dc,p: 63% 15% 10% 12%
[libx264 @ 000001f81eb0c300] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 10% 56% 2% 2% 2% 3% 2% 3%
[libx264 @ 000001f81eb0c300] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 18% 16% 5% 6% 7% 5% 7% 4%
[libx264 @ 000001f81eb0c300] i8c dc,h,v,p: 58% 18% 20% 4%
[libx264 @ 000001f81eb0c300] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 000001f81eb0c300] ref P L0: 64.0% 8.7% 21.1% 6.3%
[libx264 @ 000001f81eb0c300] ref B L0: 86.2% 11.6% 2.3%
[libx264 @ 000001f81eb0c300] ref B L1: 97.1% 2.9%
[libx264 @ 000001f81eb0c300] kb/s:842.53
[aac @ 000001f81eb5ed40] Qavg: 236.000
ffmpeg -stream_loop -1 -i input.mp4 -i input.mp3 -shortest -qscale:v 1 -qscale:a 1 -map 0:v:0 -map 1:a:0 -y out.mp4
ffmpeg version 2022-08-18-git-48be6616d0-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 33.101 / 57. 33.101
libavcodec 59. 42.101 / 59. 42.101
libavformat 59. 30.100 / 59. 30.100
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 46.103 / 8. 46.103
libswscale 6. 8.102 / 6. 8.102
libswresample 4. 8.100 / 4. 8.100
libpostproc 56. 7.100 / 56. 7.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41iso4
creation_time : 2022-08-03T18:09:13.000000Z
Duration: 00:00:12.01, start: 0.000000, bitrate: 654 kb/s
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 720x850, 515 kb/s, 60 fps, 60 tbr, 60k tbn (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Eyes v2.9.0
vendor_id : [0][0][0][0]
encoder : AVC Coding
Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Ears v2.9.0
vendor_id : [0][0][0][0]
Input #1, mp3, from 'input.mp3':
Metadata:
encoder : Lavf59.30.100
Duration: 00:00:41.74, start: 0.023021, bitrate: 128 kb/s
Stream #1:0: Audio: mp3, 48000 Hz, stereo, fltp, 128 kb/s
Metadata:
encoder : Lavc59.42
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Stream #1:0 -> #0:1 (mp3 (mp3float) -> aac (native))
Press [q] to stop, [?] for help
[libx264 @ 0000020287efc780] -qscale is ignored, -crf is recommended.
[libx264 @ 0000020287efc780] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0000020287efc780] profile High, level 3.2, 4:2:0, 8-bit
[libx264 @ 0000020287efc780] 264 - core 164 r3095 baee400 - H.264/MPEG-4 AVC codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=18 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'out.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: mp42mp41iso4
encoder : Lavf59.30.100
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 720x850, q=2-31, 60 fps, 15360 tbn (default)
Metadata:
creation_time : 2022-08-03T18:09:13.000000Z
handler_name : Vireo Eyes v2.9.0
vendor_id : [0][0][0][0]
encoder : Lavc59.42.101 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
Metadata:
encoder : Lavc59.42.101 aac
frame= 2924 fps=535 q=-1.0 Lsize= 6022kB time=00:00:48.68 bitrate=1013.4kbits/s speed=8.91x
video:5013kB audio:941kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.153298%
[libx264 @ 0000020287efc780] frame I:12 Avg QP:19.49 size: 38835
[libx264 @ 0000020287efc780] frame P:737 Avg QP:24.94 size: 4095
[libx264 @ 0000020287efc780] frame B:2175 Avg QP:26.28 size: 758
[libx264 @ 0000020287efc780] consecutive B-frames: 0.6% 0.3% 1.0% 98.1%
[libx264 @ 0000020287efc780] mb I I16..4: 17.1% 51.6% 31.4%
[libx264 @ 0000020287efc780] mb P I16..4: 0.4% 0.9% 0.1% P16..4: 24.2% 8.5% 3.9% 0.0% 0.0% skip:62.0%
[libx264 @ 0000020287efc780] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 22.5% 1.1% 0.1% direct: 0.0% skip:76.3% L0:48.8% L1:49.1% BI: 2.1%
[libx264 @ 0000020287efc780] 8x8 transform intra:57.1% inter:59.2%
[libx264 @ 0000020287efc780] coded y,uvDC,uvAC intra: 25.9% 37.6% 26.8% inter: 1.6% 1.9% 0.1%
[libx264 @ 0000020287efc780] i16 v,h,dc,p: 63% 15% 10% 12%
[libx264 @ 0000020287efc780] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 10% 56% 2% 2% 2% 3% 2% 3%
[libx264 @ 0000020287efc780] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 18% 16% 5% 6% 7% 5% 7% 4%
[libx264 @ 0000020287efc780] i8c dc,h,v,p: 58% 18% 20% 4%
[libx264 @ 0000020287efc780] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000020287efc780] ref P L0: 64.0% 8.7% 21.1% 6.3%
[libx264 @ 0000020287efc780] ref B L0: 86.2% 11.6% 2.3%
[libx264 @ 0000020287efc780] ref B L1: 97.1% 2.9%
[libx264 @ 0000020287efc780] kb/s:842.53
[aac @ 0000020287f4f180] Qavg: 118.000
Ну да, стоковой энкрдер AAC говно. Напиши -c:a libopus
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
>Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
А в чём разница? Нормально укажи битрейт, твой qscale игнорируется, если вообще существует для аудио и ты правильно написал команду.
Увы но OBS без пердоленья в режиме мануальных настроек может жать только этим энкодером в битрейт не выше 320k
Через Subtitle Edit вручную и всё
Вопрос:
- Как понять, можно ли их "оптимизировать" без видимой потери качества или же это норм размер.
- Ну и если можно, то как
PS
Посоны, сори, я не читал шапку, может там и написано это уже, но нет времени сейчас.
Выбери кодек, выбери crf и жми уже.
Сделал
ffmpeg -i input.mp4 -vcodec libx265 -crf 18 -tag:v hvc1 -preset slow -an output.mp4
Сжало до 37% от исходного (было 165, стало 62). Но звук пропал. Я так понимаю, что 100Мб занимал звук...
> -an
> Но звук пропал
Параметр -an выключает звук.
>Сжало до 37% от исходного
Дико зависит от видео. Видео с вращениями телефона в лесу или городе будут занимать даже больше место (особенно, ебануться, на 18 crf, я даже 22 очень редко ставлю), а статичный вид из окна со статичным изображением пожмётся до 10%.
Нет, плохо сделал. Читай тут https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
> Но звук пропал.
> -an
>>3196591
Ну сорян посоны, я ж в этом как блондинка. Просто скопировал со стековерфлоу.
>>3196423
Спасибо за объяснение, анон.
То есть ты рекомендуешь указывать crf 22? У меня видео какбы медицинское, с симптомами для специалиста и для истории, важно не потерять в картинке (а на глаз могу и не понять).
Для медицины данные хранят часто в lossless, потому-что артефакт сжатия на снимке можно спутать с каким-нибудь образованием. и поставить неверный диагноз.
Сам смотри, там ещё от кодека же зависит. Возьми статичное видео и наоборот динамичное, и посмотри как оно выглядит при 15-20-25 и так далее, выбрав разумный размер и подходящее качество. Проводя аналогию - может быть такое что исходный кодек кодировал видео треугольниками, а новый квадратами, и даже с повышением битрейта он добавляет новых артефактов.
Грубо говоря crf означает, что вне зависимости от размера видео и битрейта он закодирует с определённым точностью, так что разница между оригинальным и полученным видео будет не выше определённого значение, ниже crf - выше уровень соответствия.
>>3196661
Вряд ли это имеет отношение к снятому с мобилки...
> Проводя аналогию - может быть такое что исходный кодек кодировал видео треугольниками, а новый квадратами
Ну на сегодня практически все популярные lossy кодеки которые ещё живы и есть в обиходе используют ДКП, за редкими исключениями в виде ДВП кодеков. Начиная ещё с JPEG и MPEG 1 и далее вплоть до AV1 все используют ДКП в основе. Даже некогда амбициозный проект Daala строился вокруг ДКП, с надстройкой которая называлась lapped transform.
Реально кодеки отличаются алгоритмами lossless кодирования данных, набором режимов предсказания в ключевых кадрах, точностью компенсации движения, возможными типами промежуточных кадров (такие как поддержка b фреймов, альтернативные референсные кадры), и алгоритмами подавления блочности.
То есть база на протяжении всей истории видеокодеков остаётся неизменной. Усложняются лишь надстройки над этой базой.
Если мне нужна стабильная полная версия то нужен release builds и full?
> Если мне нужна стабильная полная версия то нужен release builds и full?
Да.
Аноны, выручайте. Есть у меня батник с таким содержимым:
for (процент)(процент)a in (".") do C:\ffmpeg\bin\ffmpeg.exe -i "(процент)(процент)a" -vcodec libx265 -crf 28 "(процент)(процент)~na.mp4"
pause
Кидаю его в папку с видео и он их конвертирует в эту же папку. Но по понятным причинам с .mp4 работать не умеет. Что дописать чтобы он конвертировал в другую папку (в субдиректорию или на десктоп, например)?
Опять с разметкой обосрался, про проценты вспомнил, а про астериски забыл.
>"(процент)(процент)~na.mp4"
Замени на "papka/(процент)(процент)~na.mkv" или через \
Только папку нужно создать заранее, или в начале файла прописать mkdir с именем папки.
>>3194273
Блять, после этого поста я так серьёзно призадумался. У меня тоже в одном видео такое всплывало, но я не обратил особо внимание.
И что теперь делать? Libaom не подвержен этой проблеме? То есть ключевые кадры когда меняются сцены это необходимость, без этого не обойтись?
https://jpegxl.info
В офф сборках на gyan.dev включен libjxl
Лучше через отдельный кодировщик, он умеет сжимать jpg без потери качества
>на gyan.dev включен libjxl
Последнюю версию оттуда загрузил, 5.1 full.
При запуске в параметрах сборки не указан libjxl, в списке энкодеров тоже его нет.
Мне критически важна shared версия, без неё смысла нету. Для git-full такой не вижу.
А вот версия 5.1, за 2022-07-24, а добавили якобы 2022-04-25 по чейнджлогу.
Что есть, то есть. Самому бы тоже shared хотелось.
А это зачем нужно? Чем не угодил x265/x264?
Зато сразу три либы для av1.
>Чем не угодил x265/x264?
Гугли вопрос чем отличаются gpl от lgpl, именно этим.
У этих двух библиотек несвободная лицензия
Дело не в лицензии на encoder. Сами кодировщики свободные. Дело в патентах на стандарты AVC/H264 и HEVC/H265 соответственно. Именно из-за патентов кодеки и считаются несвободными.
Тогда почему есть все остальные, кроме именно libx264/libx265?
Если сам формат того этого.
Нет, патенты не причём, у этих кодировщиком несвободная лицензия GPL, когда у остальных LGPL или MIT https://noordering.wordpress.com/2009/01/20/why-the-gpl-is-not-free/
Ребят - а нахуя вы сжимаете?
Что это за хобби у вас такое?
>а нахуя вы сжимаете?
Чтобы место меньше занимало.
>Что это за хобби у вас такое?
Обычное, что не так?
А вот этого я не знаю. Спроси у тех кто собирал этот билд.
> нахуя вы сжимаете
Хочешь ты, предположим, выложить в /zog какой-нибудь видеофайл, скачанный с Ютьюба.
А просто указать ютьюбный адрес не получится, поскольку видеофайл на самóм Ютьюбе ужé стёрли.
Но в /zog можно не больше 40 мегабайтов.
А у тебя yt-dlp скачал с Ютьюба 95 мегабайтов.
Значит, поневоле придётся сперва сжимать.
> Libaom не подвержен этой проблеме?
Подвержен, но там говном (из-за несовпадения ключевого кадра и начала новой сцены) становится только один кадр.
https://bugs.chromium.org/p/aomedia/issues/detail?id=3070
Не читал, но там был патч, связанный с этой ишой
Появилась проблема после того как я перешёл с премьера на давинчи. Настройки рендера на 2 скрине. Может что-то с цветовым диапазоном?
Вместо yuv 422 8bit, ставь yuv 420 8 bit и только его. Ну и еще кодек h264, x264.
Я лослесс хотел использовать при монтаже.
Причем тут монтаж и рендер?
Монтаж + рендер в лослесс, а из лослесса уже в вебм.
ну так, когда кодируешь в вебм уже сделай в yuv420p 8 bit. Нах тогда твои настройки рендера в давинчи тут, ты же не сказал, чем перекодируешь из лос в вебм. У тебя сейчас в вебм стоит yuv42210bit. Если через ffmpeg кодируешь, то команду указываешь дополнительно -pix_fmt yuv420p в настройки видео.
Я почему-то был убеждён, что у vp9 какой-то один свой колорспейс и он всегда его меняет. И вот я допёр что это не так, захожу сюда, а ты мне тоже это говоришь. Спасибо, сейчас напердолю.
В чём разница -pix_fmt и format?
формат вообще к кодеку относится как знаю. pix_fmt правильно использовать, другого нигде не видел.
Сжатие - это компромисс между дисковым пространством и интернет-трафиком с одной стороны, и электричеством, человеческим временем и мощностью железа с другой. Если у тебя слабый процессор, дорогие тарифы на энергию и много места на дисках, и стоит цель хранить медиа - сжимать не нужно. Если у тебя мощное железо, дешёвое электричество, и медиа-файлы нужно отправлять по интернету или хранить на переносном устройстве с малым объёмом хранилища - нужно сжимать.
Слушай, готового решения не дам. А чем ты режешь? По идее, большинство кодеков при нечётном значении просто выдаст ошибку. А вот vp9 просто сделает так как ты просишь без проблем. Помню находил команду, чтобы для чётности добавлялась строчка серого цвета. Некогда искать сейчас.
https://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divisible-by-2
Вот, нашёл о чём говорил. Вообще уже не помню что я имел в виду, спрашивая "чем ты режешь?", когда вроде ты всё написал. По ссылке не совсем твоя проблема, но попробуй в эту сторону копать.
ffmpeg -i input.mp4 -i metadata.txt -map_metadata 1 -c copy output.mp4
Как записывать экран с игрой без серьёзных просадок производительности в игре и без потери плавности на видео? Допускается вариант с записью раздутых плохо сжатых файлов в реальном времени и дальнейшем их сжатием. Я так и делал, пытаясь записывать lossless, но, кажется, из-за нехватки пропускной способности моего usb hdd видео получилось дёрганым. Сжимая в реальном времени на высоких битрейтах получал меньшие но лаги как в игре так и на видео. Записывая на ssd ситуация чуток улучшилась. Записывал через OBS, не нашёл пригодных к использованию настроек.
> Как записывать экран с игрой без серьёзных просадок производительности в игре и без потери плавности на видео?
Через утилиту, встроенную в драйвер видеокарты, типа shadowplay
>shadowplay
Более говноедский софт поискать нужно.
Перекодирование из jpg без потерь не работает, а если и работает, то размер только уменьшается.
Объясните, почему я беру картинку, кодирую её как -c:v png, потом открывают исходную jpg и полученную png, и между ними получается разница почти в 16 пунктов (из 255).
Предположу, что это как-то связано с цветовыми пространствами 709-601, и со всякими yuv420p, yuv422p. Это конечно всё очень хорошо, но почему я не могу взять уже заданный файл, сохранить его в png без потерь и чтобы получилось то же самое, как если бы я сразу открывал jpg?
Вот, вопрос, как сделать так, чтобы я взял jpg, перекодировал его в png, и открыв в пеинте получил бы одинаковые изображения, а не разные? Причём, я уже подумал что это в моей программе косяк и она не может jpg открыть, так нет, в крите то же самое, цвета сбиваются.
>>3200899
Компьютеры писали в полном разрешении с экрана ещё десять лет назад, сейчас это потребляет вовсе 10% ресурсов по сравнению с самой игрой, потому что мониторы и фпс остались такими же с условными 1920х1080 в 60 фпс, а игры стали тяжелее и компьютеры быстрее.
Проблема не в кодировании видео, а в алгоритме захвате, который видимо не очень эффективный.
В ffmpeg оно не работает, надо свой кодировщик
Это потому что у ffmpeg архитектура такая, что кодировшик исходный файл не получает и отдельный от декодера, и сжимает данные заново не имея возможности обратиться к оригиналу?
А как тогда его настроить?
Ютуб для стримов в 2к советует от 9к до 18к. Если поставлю 15к для записи на диск, не будет ли слишком хуево?
Хочу потом резать вебмки и лить на двачи, пережав vp9. То есть сурс должен быть ну не совсем уж печальным.
Тут же в посте вопрос по шебмам.
Жму так:
-deadline good
-cpu-used 3
-b:v 1-2M
Результаты кочуют по двачу, но в частности можно увидеть тут:
https://2ch.hk/v/res/7558295.html#7560239
https://2ch.hk/v/res/7558295.html#7560248
Подходящий битрейт зависит от содержания видео. Если у тебя 2d игра в изометрии, или даже просто с видом сверху, то для "не слишком хуевого" качества подойдёт в четверо меньший битрейт, чем для шутера с прыжками и перекатами.
А поставить constqp режим религия не позволяет, который сам в зависимости от содержания видео возьмёт битрейта достаточно, для передачи "не слишком хуевого" качества, по типу, что если ты будешь листать сайт или поставишь всё на паузу, то он вообще минимум битрейта будет расходовать?
>>3200917
В общем очень условно потестил, а заодно и более древние кодеки (и ещё одиночные кадры libaom-av1 и vp9).
Вот таблицы для трёх картинок в разных форматах и разного размера, в качестве оценки среднеквадратичная разница (в rgb-представлении, что очень условно) и максимальная разница.
Интересно что будет, когда мне подскажут как jxl запустить.
Проблему "решил" просто ещё и исходное изображение в png перегоняя, чтобы там не было проблем с этим преобразованием цветов.
Мяу, я всё настроил, чтобы было удобно можете ещё кодеков подкинуть для проверки или картинок.
> А поставить constqp режим религия не позволяет, который сам в зависимости от содержания видео возьмёт битрейта достаточно, для передачи "не слишком хуевого" качества, по типу, что если ты будешь листать сайт или поставишь всё на паузу, то он вообще минимум битрейта будет расходовать?
Constqp и crf это разные режимы! То что ты написал относится к crf
Но к qp в целом тоже, просто не так явно, но принципы адаптивного битрейта всё ещё сработают.
Там только не среднеквадратичная, а средний квадрат делённый. Опечатался немного, а то задумался что значения маловаты.
Чтобы получить среднеквадратичную в шкале 0..255, нужно умножить на 255 и извлечь корень, примерно вот так масштабируется:
0.01 -> 1.60
0.05 -> 3.57
0.10 -> 5.05
0.20 -> 7.14
0.50 -> 11.29
С какими настройками писал? Поставь CQP 22 и посмотри. Я хз какие проблемы там можно увидеть. Я заходил в шутан и на максимальной чувствительности мыши прокручивал мышь в бок, потом открывал получившееся видео и каждый кадр был идеально чёткий. При этом, фон в игре состоял из природы с деревьями и всем таким, то есть довольно сложная картинка. Равнины Эйдалона в варфрейме.
>>3200904
Тот же нвенк, что и в обс, только cbr без альтернатив, в то время как обс может писать в cbr, vbr и cqp и даже лослесс. Никак шадоуплей не может писать качественнее OBS.
>>3200912
Двачую. Я каждый раз в шоке с "игровых журналистов" которые деньги вроде зарабатывают этим, а всё равно пишут шадоуплеем и жалуются "ой, у меня не захватывалось, ой у меня оверлей шадоуплея мерцает на записи, ой...".
CQP это то, чем приходится пользоваться за неимением CRF. Хз почему нет, возможно в реальном времени нельзя.
>Никак шадоуплей не может писать качественнее OBS.
Может писать эффективнее и незаметнее для компьютера, если нвидия сделала костыль, так что только у них есть доступ к фичам видеокарты по своим протоколам, и если это ещё не зареверсинжирили. Или если видео на каком-то более глубоком уровне драйвера захватывается без лишних передач данных, это уже к слову не о кодировщике, а именно о захвате видео.
Но лишние программы ой как не хочется на компьютер держать, а этот nvidia expirence ещё и вроде бы с регистрацией, вообще офигеть.
>>3201362
nvenc просто такое не умеет, у него только cq, а x264 - пожалуйста, в реальном времени вполне пишет, но сильно загружает процессор.
>nvenc просто такое не умеет
Понял. Жалко.
>>Никак шадоуплей не может писать качественнее OBS.
>Может писать эффективнее и незаметнее для компьютера, если нвидия сделала костыль, так что только у них есть доступ к фичам видеокарты по своим протоколам, и если это ещё не зареверсинжирили. Или если видео на каком-то более глубоком уровне драйвера захватывается без лишних передач данных, это уже к слову не о кодировщике, а именно о захвате видео.
Да, тут ты прав, но это почти теория заговора. OBS развивается при поддлержке нвидии в том числе. Поддержка, конечно, не значит, что они раскрывают все свои карты, но всё же. Вероятность имхо мала. ОБС жрёт на 1-2 процента больше, скорее всего из-за моделирования сцены. В экспириенсе, понятно, такой функционал просто отсутствует.
>Но лишние программы ой как не хочется на компьютер держать, а этот nvidia expirence ещё и вроде бы с регистрацией, вообще офигеть.
Да, с регистрацией, но можно просто по гуглоаку зарегистрироваться и зайти. Экспириенс не так бесполезен. Мне нравится Ansel (работает без включения оверлея). Позволяет делать скрины в ебическом разрешении. Но это так, побаловаться. А ещё можно посмотреть что та или иная опция в игре меняет. Есть неочевидные моменты иногда. Жалко экспириенс может только пресет настроек применить, руками из экспириенса настроить ничего нельзя. Ещё апскейл нейросетевой можно включить через него. Который dsr.
Ставить это ради записи не стоит. Качества там лучше не будет - уверяю, а UX там на дне.
>который сам в зависимости от содержания видео возьмёт битрейта достаточно, для передачи "не слишком хуевого" качества, по типу, что если ты будешь листать сайт или поставишь всё на паузу, то он вообще минимум битрейта будет расходовать
Как тебе уже написали, это больше про CRF. CQP будет квантизировать абсолютно все кадры одинаково, адаптивности у него нет никакой. Именно поэтому я ставлю постоянный битрейт и не трачу место на диске зря.
Тебе constant о чем-нибудь говорит? CQ - не аналог CRF даже близко. Кури мануалы.
>я ставлю постоянный битрейт
*и приемлемый, а не 50м/сек
Ты не совсем прав. CQP будет таки адаптировать битрейт под сложность картинки. Минута рабочего стола и минута игры будут различаться очень прилично. 5 мб против 350 мб очень реально. Даже CBR экономит битрейт в простых сценах, если память не изменяет.
Ну и вообще cqp > cbr для записи. Как минимум за счёт психовизуальной модели - он сжимает кадр не равномерно, а даёт приоритет качества подвижным частям, так как человек будет смотреть туда. Субъективное качество такого видео выше, хотя объективно это не так.
мимо
>Который dsr.
Он включается у меня в панели управления и без экспиренса.
>>3201385
>CQP будет квантизировать абсолютно все кадры одинаково
А это разве и не значит, что разница между исходным видео и полученным будет не выше определённой? И это напрямую говорит о том, что сложное видео с резко меняющимися кадрами будет кушать больше битрейта?
А в crf просто ещё оптимизации про движение и восприятие цветов глазом, лучше на 10%, но в целом надстройка над более простым и математическим cqp.
Я взял это https://github.com/libjxl/libjxl/releases
Кстати, это нормально, что оно потребовало наличия некоторых brotlidec.dll и brotlienc.dll, которые в уже скомпилированном виде нигде не нашлись, и мне пришлось загрузить код отсюда (там только код, без бинарников) https://github.com/libjxl/libjxl/releases - скомпилировать (слава богу, оно с первого раза без ошибок скомпилировалось, потому что понятный cmake использует), и потом там появились файлы libbrotlidec.dll и libbrotlienc.dll, у которых пришлось убрать префикc lib, и только после этого оно заработало?
Отконвертил папку с фотографиями какими-то с трёх разных мобильников.
Вроде и неплохо, но не так уж впечатляет, к тому же одну фотографию, нормальную, без разрешения в 10к и с чётным размером не смог перевести.
Предпросмотр в виндоусе работает, миниатюры загружаются, но оче долго.
А видеокодек без потерь пережимающий x264 будет, или просто на основе этого jxl?
В целом по соотношению размер-качества он на голову выше webp...
>Никак шадоуплей не может писать качественнее OBS.
Писать может и нет, а вот захват экрана там производится собственной технологией , которой нет в обс.
>Тот же нвенк, что и в обс, только cbr без альтернатив, в то время как обс может писать в cbr, vbr и cqp и даже лослесс.
Также это всё тоже меняется, но через реестр.
кукла нормально кстати воспроизводит, только сжимает к центру.
А ещё обрати внимание на BPG (основанный на h265, если на ошибаюсь - или там уже что-то новое на h265 придумали, не смотрел) и avif (основанный на av1). И на jxl, да - он прям очень хорошие картинки выдаёт, и даже на катастрофически низком битрейте в 2% от исходного он выдаёт узнаваемую картинку, когда все остальные форматы пятна или квадраты размытые. И ещё он уже хорошо внедряется в виндоус, и предпросмотром и миниатюрами.
Суть: пытаюсь перекодировать исходник для теста libx264, но файл не воспроизводится. Когда кодирую hevc, все окей. В чем сука может быть причина, что плеер отказывается есть самый обычный кодек?
test - hevc
test_2 - libx264
-ss 00:05:30 -i source.mkv -t 00:02:30 -c:v hevc -c:a aac test.mkv -работает
-ss 00:05:30 -i source.mkv -t 00:02:30 -c:v libx264 -c:a aac test_2.mkv - не работает
Плагин для 265 установил.
Следующим постом вкину ffprobe сурса.
Видео не конвертнул. Короче такая хуета.
В одном случае у тебя ускоряется дорожка без изменения формы волны, во втором случае идёт преобразовывание тембра, что намного более сложный код.
Если не ошибаюсь - одно делается как -af asetrate=441002.0,aresample=44100, а другое как просто -af asetrate=441002.0, или что у тебя там вместо 44100.
А в плеере это где-то можно сделать? Я так понял у тебя для перекодирования параметры? Я просто выбираю в плеере "увеличить скорость" и смотрю.
Спасибо, анончик! Сам нашел вот эту хрень. Теперь нормальный голос, а не ебучий мультяшный
В твоём — понятия не имею.
В моём вот, есть два алгоритма с компенсацией тембра, есть без обработки завышающий частоты, и ещё один из ffmpeg.
У тебя видео 10 бит, h264 такой формат аппаратно не поддерживают. Напиши -pix_fmt yuv420p
Сработало, спасибо. Только где мне покурить значение
>-pix_fmt
?
Гугл не ищет.
Все нашлось. Теперь вопрос в том, какие параметры передать кодировщику, чтобы качество не пострадало.
И, что не так? Это единственный сервис с музыкой без потерь, где нету ебучего DRM
streamsize+сам контейнер mkv 16мб. И ничего это не много.
>av1
Пытался я в него сжать. Как итог - сжималось не быстро (впрочем, x265 на хороших настройках жмёт намного дольше), вес крошечный, но на глаз качество не идеальное. В плеере чтобы промотать я ждал по полторы секунды после нажатия стрелок, что не оставляет шанса этому кодеку. Так же встретил предупреждение в плеере "[mkv] Discarding potentially broken or useless index." и многочисленные ошибки о невозможности аппаратного декодирования.
>x265 на хороших настройках жмёт намного дольше
Ты там туттуру совсем? Точно? А в случае чего у av1 тоже есть совсем смертоубийственные настройки.
У меня 25-минутное аниме сжимало 3 часа 50 минут - -c:v libx265 -crf 19 -preset slower -pix_fmt yuv420p10le -bf 11 -sn -an. Я параллельно кодированию активно пользовался ПК. С более низкими настройками сжимало 2 с половиной часа, но тогда на некоторых кадрах был виден banding (вроде так называется). Я руководствуюсь логикой "сжав хотя бы в 3 раза, мне уже не придётся покупать 2 новых диска".
av1 выглядит интересно, но с такой ужасной производительностью пользоваться им невозможно. В том ли дело, что на моей карте не доступно ускорение, или в том что я рукожоп, или в том что, дабы не ждать долго, я решил проверить av1 на 30-секундном обрезке, не знаю.
У меня 20 секундное видео кодировалось дольше 4 часов в aom-av1. А ты про 25 минут, оно две недели будет кодироваться.
Сейчас конечно svt расплодился кодирующий быстро (заметно быстрее дефолтного libvpx-vp9), но я сколько кадры не сравнивал, до дефолтного aom-av1 он решительно не дотягивает, хотя по соотношению размера-качества это лучше всех vp9-h264-h265 даже так.
А скинь свои по братски, чтобы мог сжимать порядочно.
>а-то орут
Пусть орут, далей webm, пожалуйста.
>webm не могут на яблоке
iTODDLERS BTFO
Анон, я не то, чтобы сильно соображаю в кодировании, поэтому и советовать ничего не могу.
webm и mp4 - это контейнеры, тупо обёртка для кодеков, хранящих непосредственно сжатие. mp4 - проприетарный формат с лицензионными отчислениями и ограниченным набором кодеков, поддерживается каждым утюгом, чтобы денег больше несли в MPEG LA. mkv - хранит любые кодеки, шрифты к субтитрам, его можно обрабатывать в годном mkv tool nix, признан на торрентах, в некотором говно-софте (видеоредактор Apple) не будет работать. webm - лайтовая версия mkv под кодеки гугла.
>в некотором говно-софте (видеоредактор Apple) не будет работать
Да почти все серьёзные видеоредакторы, что я использовал, игнорируют webm, mkv и vp9.
Навязывают гоям платные форматы.
Так, тест показал что два прохода выдают файл идентичный одному проходу.
vp9 кодировался чуть больше трёх минут. Два прохода.
svt-av1 в два прохода 8.5 минут. В один не запомнил.
AV1 - полчаса.
Значение crf всезде 35, что для разных кодеков не равнозначно. Итого, эксперимент не очень имеет смысл, но вебм с хуйнёй из игр всё ещё лучше делать на vp9 имхо. Быстрее, не сильно хуже и поддерживается везде.
ав1 тоже в два прохода.
Столбец веса бы ещё вывел
Ну и ещё надо упомянуть что у авт пресет 3. У ав по умолчанию, у вп9 good.
В adobe раньше были, а потому специально выпилили.
Как мы видим, у опуса более ясно выраженный срез верхних частот, но сами верхние частоты выше, чем в aac, а так же помимо громких звуков opus сохранил шум и прочий ambient. В самом низу у aac видна жёлтая полоса, тянущаяся через весь файл, которую тем не менее не слышно.
opus весит 25 880 Кб, aac - 27 604 Кб.
Очевидная победа свободного опуса. Aac выиграл только в скорости кодирования.
Команды:
ffmpeg -i file -vn -sn -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" audio.opus
ffmpeg -i file -map 0:a:0 -c:a pcm_f32le -f wav - | "qaac_2.76\x64\qaac64.exe" --ignorelength -V 90 - -o audio.aac
А что за окно в фурье-преобразование? Какое-то хреновое окно, всё замыливает по частотам - или просто цвета такие неудачные?
У тебя в фонограме какой-то свист в раёне 15-16 кГц. Притом частота этого свиста плавает, то чуть выше, то чуть ниже. Громкость тоже плавает.
После применения фильтра получается второе. Видите дрожание по углам? Причём, я погуглил, и такое не только на моём видео.
И вот ещё видео. Тут видно, что фильтр исходный кадр просто поворачивает и сдвигает, без учёта перспективы, считая что у камеры угол обзора очень маленький и вид как из телескопа.
Вот, на четвёртом видео я не сдвигаю камеру, а просто поворачиваю, и при этом прямоугольный экран превращается в трапецию, которую как не сдвигай - квадрат из неё не получишь.
Есть фильтр это учитывающий, или нужно велосипедить самому?
Есть вариант пережать прямоугольную проекцию камеры в сферическую, применить обычный vidstabtransform, и потом вернуть обратно - полностью проблему это не решит, но кодится просто и артефакты по типу лёгкого дрожания почти полностью решат.
Просто должно же уже такое быть, в камере на телефоне есть свой фильтр программный, и он ёлочки без дрожания делает, потому что знает угол обзора камеры и может это скомпенсировать при поворотах.
> очередные свидетели спектрограмм оценивают качество по частоте среза ФНЧ
Кодеки можно оценивать исключительно слепым прослушиванием на большой выборке. Частоту lowpass фильтра задрать можно и на mp3, спектрограмма будет изумительная, но тогда ты ради верхов начнёшь терять данные из слышимого спектра.
> Кодеки можно оценивать исключительно слепым прослушиванием на большой выборке.
Нет, только визуально с помощью спектрограмм.
Ну критические обсёры, которые бывают если кодировать встроенным в ffmpeg aac на низких битрейтах видны на спектрограмме, но такие артефакты отчётливо слышны и безо всяких там слепых тестов.
Плюс пипе сломан вроде с парой ффпмег.
До этого еще старый aom юзал, хоть и чуть-чуть долговато, но качество точно хорошее было даже при 500к битрейта.
Параметры такие:
>pastebin.com/RTC8gDVB
Ебать дебил, что за конченные параметры? Сам ввёл полнейшую хуйню, ещё и жалуется. Нахуя два прохода?? Нахуя труба? Сука, оттуда такие долбоёбы берутся
А ладно подожди, два прохода нужно, но параметры всё равно так себе
>Ну и зачем этот ваш svt-av1 по качеству не лучше уж vp9
У меня дефолтный svt кодирует в 20 раз быстрее дефолтного vp9, и соотношение размер-качество лучше.
То что я запарился и откодировал по минуте видео в aom - там конечно сильно лучше качество, чем svt - но я не ставил тяжёлые пресеты у svt, да и если кодек кодирует со скоростью aom - то это то же самое, что его нету.
Выше видосики выставил пресет 0 вообще, но мне кажется 2пасс багнут, потому что в 1пасс crf он долго кодировал вообще. А те как молния пронеслись, поделись какими-нибудь настройками для svt свои, тоже попробую.
Дефолтные настройки, я же написал.
-c:v libsvtav1 -b:v 0 -crf 40
Только crf менял, и -g 300 прописывал. Ещё потыкал пресеты, но десятикратное увеличение времени кодирования ради разницы в 2% меня не интересует - я и забил.
>Дефолтные настройки, я же написал.
ааа
> Ещё потыкал пресеты, но десятикратное увеличение времени кодирования ради разницы в 2% меня не интересует - я и забил.
Ну прямо на низких может и 2, но повыше 5-15%, а это уже существенно.
На ввод поставил png, и получившийся jxl файл ничем не открывается.
>>3202720
Открывается через ffplay ><
А вообще можешь вот это поставить, там будут превью и открытие через просмотрщик виндоус.
https://github.com/mirillis/jpegxl-wic
out.jxl: Invalid data found when processing input sq= 0B f=0/0
>>3202722
В любом случае я не буду менять Honeyview на ffplay ради формата. Но, подозреваю, ошибка кроется в другом.
> В целом по соотношению размер-качества он на голову выше webp
Ну webp без потерь только увеличит jpg, потому меня интересует как ты кодировал и что и реально ли оно уменьшило jpg без потерь?
>Honeyview
В этом древнем кале конечно не будет поддержки новых форматов.
>>3192842
Зачем пережимать лосси джипег в webp, если можно пережать в jxl без потерь?
>>3192845
>jxl уже внедряется везде где только можно, в браузеры поддержку уже давно завезли
>>3201460
>Кстати, это нормально, что оно потребовало наличия некоторых brotlidec.dll и brotlienc.dll, которые в уже скомпилированном виде нигде не нашлись, и мне пришлось загрузить код отсюда (там только код, без бинарников) https://github.com/libjxl/libjxl/releases - скомпилировать (слава богу, оно с первого раза без ошибок скомпилировалось, потому что понятный cmake использует), и потом там появились файлы libbrotlidec.dll и libbrotlienc.dll, у которых пришлось убрать префикc lib, и только после этого оно заработало?
Отличное "повсеместное внедрение", чтобы попробовать сам поебись с конпеляцией энкодера, энкодер сам себя не конпелирует.
Да, реально, ни одного пикселя разницы.
Но там 20% уменьшения, я же запостил цифру. Другие фотографии пока не пережимал.
>>3202732
Я же запостил всё. Либа с jxl была в уже скомпилированном видео, но требовал dll-ки от brotli, которые я сделал сам. И вот батник как на втором, на которые я мышкой перетягиваю файлы.
Тебе бинарники brotli в архив скинуть или что?
>>3202737
> если можно пережать в jxl без потерь?
Фотография на 5 мб. Информации на неё на 1 мб, так как оптика в мобилке говно и там всё размытое с завышенном и зашумлённом разрешении. Но webp поддерживается в дискорде и на другой борде, а jxl только у меня на компьютере поддерживается.
>Отличное "повсеместное внедрение"
У меня браузер не поддерживает, даже когда я в настройках в конфиге перенастроил. Превью на виндоусе грузяться по секунде на фотографию, когда для webp/jpg загружается по 20 штук за секунду.
> Да, реально, ни одного пикселя разницы
> там 20% уменьшения
Ну норм.
> У меня браузер не поддерживает, даже когда я в настройках в конфиге перенастроил. Превью на виндоусе грузяться по секунде на фотографию, когда для webp/jpg загружается по 20 штук за секунду
Не норм, лосси джипег и так не то, чтобы дохрена весит, к тому же выше говорят 95% вебп не шибко шакаля вес уменьшает(когда будет время попробую). Раз уж ты так любишь тестировать, то может пожмёшь png в лосслесс webp и в этот лосслесс jxl для сравнения веса? Или говно план?
> Либа с jxl была в уже скомпилированном видео
> но требовал dll-ки от brotli, которые я сделал сам
Ты понимаешь, что не все здесь будут сами делать .dll, которые ты найти не смог, так что равносильно отсутствию готового энкодера.
>которые ты найти не смог
Я тоже удивился, что я не нашёл ни одного билда brotli под виндоус.
Гугл и сам бы мог его выложить, и даже если нет - обычно у всяких программистов социокексиков куча гитхабов с билдами. К тому же оно тупо одной кнопкой скомпилировалось, хотя обычно со всеми либами такими куча неожиданных ошибок вылезает в cmake или ещё где...
>То может пожмёшь png в лосслесс webp и в этот лосслесс jxl для сравнения веса?
Да не вопрос. Какие взять?
Скриншоты? Фотографии пережать в png, и посмотреть что с ними будет? Рисованные рисунки с исходником в png?
>95% вебп
OpenCamera на андроиде кстати сразу в webp может сохранять с указанным качеством, я ставлю качество 92 и получается сильно лучше, чем если jpg любого качество пережимать в webp уже после.
А ещё у jxl тоже есть lossy режим - который работает лучше webp. Между прочим webp устроен на основе vp8. Когда ты последний раз хотя бы webm видел в vp8?
> Какие взять?
Какие тебе удобнее, добра полно от скриншотов, до артов с пиксиово, мы же прорабатываем вопрос универсальности формата, в общем виде интересует замена всего зоопарка на jxl (когда к нему допилят поддержку и декомпилятор адекватный, если это возможно, чтобы работал на кофеварке и не требовал 20 секнд на одно превью)
> OpenCamera на андроиде кстати сразу в webp может сохранять с указанным качеством
Ну это касательно фотографии, кому-то полезно, я не думаю, чтобы когда-нибудь лично мне понадобится.
jxl без потерь уменьшил jpeg - было 1.09 мегабайт стало 790 килобайт.
Слушай скинь вообще всё сразу готовое собранное, я ничего не смог запустить.
Любой, который ffmpeg в качестве бекэнда цепляет. И по идее такие должны быть.
>>3202777
Там только dll-ки с avx2, если у тебя слабый ноут или офисный компьютер - то может не заработать.
https://files.catbox.moe/a22h0i.zip
В батнике можно другие параметры дописать (чтобы lossy jxl попробовать, например), просто мышкой на него файлы перетаскиваешь (как тут >>3194692)
У меня никаких dll не требовало.
Ну видимо этот мусор у тебя уже был в системе, dll точно требует.
>мусор
С чего бы? Мусор воняет и плодит жуков, а dll лежат себе тихо и не мешают.
Сначала заметил это после того как конвертировал через Webm for Lazys, решил что это с ним какая-то хуйня. Adobe Premier вообще отказался открывать этот файл. Boram тоже самое выдал, но только на нём я обратил внимание, что там две видео дорожки.
Что теоретически можно с этим делать, кроме скачивания другого рипа?
Я qimgv юзаю, но он от украинца, мало ли что.
Нихрена непонятно чего ты хочешь. У тебя hdr перекодируется в sdr, поэтому и теряется. Причем тут вторая дорожка вообще непонятно, скорее это просто превью к видео.
Качай SDR обычный рип.
>У тебя hdr перекодируется в sdr,
А разве при отображении на обычном мониторе hdr просто на стадии рендера не преобразуется в sdr? Почему анон не может это же преобразование получить оффлайн, а не во время просмотра?
Не поняв. Перекодируя вообще трудно сделать, что в одну сторону, что в другую, насколько знаю. Сплошной пердолинг.
Что сказать-то хотел?
Я думал, что быстрее - значит меньше компрессия и выше скорость.
Но получается вот что:
# input.mp4 - 165.8MB
ffmpeg -i input.mp4 -c:v libx265 -crf 18 -preset slow -c:a copy output_libx265_crf18_slow.mp4
=> 63.7MB
ffmpeg -i input.mp4 -c:v libx265 -crf 18 -preset medium -c:a copy output_libx265_crf18_medium.mp4
=> 56.4MB
ffmpeg -i input.mp4 -c:v libx265 -crf 18 -preset fast -c:a copy output_libx265_crf18_fast.mp4
=> 50.6MB
То есть пресет это про качество?
А если подкорректичуешь цифру crf (там можно дробные значения скармливать libx265, если не ошибаюсь), так чтобы размеры файлов совпадали, то на slow-пресете качество будет лучше.
Хотелось бы замутить скриптик наподобие пикрил для простоты запуска чтоб нужно было лишь прописать название скрипта+название файла и чтоб как на пикриле к названию файла прописалась дата время. Это я уже не смог нагуглить сорян аноны
А может просто обс использовать?
Там кстати кому интересно, av1 и h264,hevc 10 бит запись завезли в новую 28 версию. Также теперь можно отдельный звук приложения захватывать, то что должно давно было появиться.
>к названию файла прописалась дата время
Пиши команду date в специальных кавычках (кнопка Ё в английской раскладке)
`date +%Y.%m.%d-%H.%M`.mp4
>Также теперь можно отдельный звук приложения захватывать, то что должно давно было появиться.
Реально? Как-то я это пропустил. Хотя, я делаю это войсмитром, но друзьям домохозяйным плагин для этого скидывал.
Да реально но с припиской бета пока. Тоже воисмиттер юзаю, но также и для чуть других целей. А если чисто распараллеливание звука надо, то можно и удалять его, если чисто для обс был.
Не, я звук обрабатываю микрофону и прочее. Кстати, в следующей версии будет охуенный компрессор и денойс и вообще всякая ёба. Воможно, вст хост станет ненужен многим.
Ну и отлично, хоть какое-то нормальное развитие появилось.
А ты не догадался как?
screen.`date +%Y.%m.%d-%H.%M`.mp4
Это только на дату же чел мне еще нужно название задавать при подрубе записи. типа ./ffmpeg.sh 2ch и пишет он это в файл 2ch_070922-195200
Тогда так
$1.`date +%Y.%m.%d-%H.%M`.mp4
Давно пора прикрутить мультистрим из коробки. Что стоит дублировать уже закодированный поток бай дизайн?
Хочу свести
[code]scale='if(gt(ceil(iw/2)2,ceil(ih/2)2),min(%d,ceil(iw/2)2),-2)':'if(gt(ceil(iw/2)2,ceil(ih/2)2),-2,min(%d,ceil(ih/2)2))'[/code]
До нормального вида
что такое енкодеры и енкодеры блять
пикчу можно хранить просто как набор пикселей, предствление бывает разное, rgb, yuv. Но не суть, в общем чтобы вывести ее на экран (без расчета скейлинга) нужно произвести тривиальные вычисления, но считать много данных.
Пикчи можно сжимать, базовых типов преобразований не слишком много, но готовых алгоритмов выстроили предостаточно. Теперь можно меньше информации хранить, но надо поработать ЦП чтобы сжать и разжать обратно в пиксели.
Пикчи сжали, отлично, можно в теории видео как слайдшоу из них делать. Но все равно хуево, весит много. В природе у большинства видео большая часть кадров не так сильно отличается от друга. Будем одни кадры сжимать как картинки, а другие будут ссылаться на них и дельты будут меньше весить. Снова доп работа процессору, но ничего, зато весит приемлемо.
Encoder, кодировщик - здесь это программа, которая будет представлять картинки в виде, более пригодном для передачи информации, в том числе, для уменьшения количества информации в исходных изображениях и звуке. Соответственно, decoder, декодер - программа для восстановления из потока данных примерного содержания изображения или звука.
Программ таких много, на выбор, у каждой свои особенности и задачи, свой способ представления как со стороны изображений и звуковых сигналов, так и со стороны кодовых последовательностей в потоке данных.
Простая пересборка в хорошо документированной mkvmerge решает в т. ч. указанную тобой проблему. Зачем тебе теперь mkvclean?
Если уже так тебе это всë нужно с переменными и условиями, то почему бы тебе сразу не использовать какой-нибудь vapoursynth?
Раскодируй, да посмотри, отличаются ли raw pcm!
Скорее всего, различаются данные только в полях codec_private, в которые заносят всякое служебное - например, номер версии библиотеки кодера.
>А разве при отображении на обычном мониторе hdr просто на стадии рендера не преобразуется в sdr?
Не обязательно.
https://en.wikipedia.org/wiki/DisplayPort#Refresh_frequency_limits_for_HDR_video
>Что теоретически можно с этим делать, кроме скачивания другого рипа?
Показать нам на pastebin вывод midiainfo для начала. Можно другой интернет-блокнот использовать.
Звуковые сигналы тоже кодируются окнами. Кодер mp3, например, набирает в окно 1152 отсчëта, а кодер aac - 1024. Окно решает сразу несколько задач - и определяет единицу кодируемой последовательности, и определяет единицу передаваемой последовательности. Размер окна определяется из удобной размерности свëрточного преобразования и из продолжительности последовптельности во времени, сходном с минимальной длительностью акустического сигнала, воспринимаемой слухом человека.
Немного не так.
Погугли regsvr32, regsvr64, ole и прочую нечисть!
Вроде работает только на новых rx6600, читай патчлог обновления и всё.
Там же в отчëте было что-то ещë? Причину понять сложно. Можешь нам файл и строчку команды дать?
Что думаете о моей команде для кодирования в svt-av1?
echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -vn -sn -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~
Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
Склеиваю оба файла в mkv уже после того, как они готовы на 100%. В теории, если склеивать на лету, то какие-то технические метаданные о времени запишутся в конец файла, и тогда файл будет открываться медленно (будет чтение файла от начала до конца).
opus выбрал за лучшую спектрограмму относительно aac >>3202282. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.
echo и time нужны для удобства - знать, когда я начал и закончил кодировать.
Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе.
>-pix_fmt yuv420p10le
Что это?
Разве цвета не кодируются в восемь бит, потому что почти все экраны допускают только значения компонент от 0 до 255, а все веса в дискрептном косинусном преобразовании всё-равно имеют другое представление? Что такое 10 бит с математическо-программистической точки зрения?
Вроде бы mkv не mp4, и у него нет проблем с чтением конца файла. То есть ещё до конца кодирования файла я могу его открывать и смотреть (готовую его часть) без дополнительных настроек.
https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
>При использовании 10 бит, видео будет сжиматься лучше, даже если исходный был в 8 бит. Но немного дольше кодируется видео, и может не поддерживать видеокарта (H.264 и VP9 никто не поддерживает, H.265 часто встречается, AV1 если есть в видеокарте, то обязан поддерживать) Это из-за того, что при сжатии значения округляются, а для 10 бит будет меньше ошибки. Он включается параметром -pix_fmt yuv420p10le, а 8 бит это -pix_fmt yuv420p.
Не работает ссылка.
То это это про битность кодирования отдельных гармоник после косинусного преобразования?
Или про битность RGB->YUV преобразования? Да по идее оно и так в плавающих числах должно производится, чтобы избежать проблем.
↓
https://2ch.hk/s/res/3205384.html
↑
ПЕРЕКАТ