1651073624816.png400 Кб, 2000x2000
FFmpeg и общий кодирования видео тред №8 /ffmpeg/ Windows 10: Chromium based 3205384 В конец треда | Веб
FFmpeg и общий кодирования видео тред №8

В прошлый раз мы весь тред обсуждали тонкости сжатия и разбирали команды.

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 (М)
Тред №7: https://2ch.hk/s/res/3181555.html (М)
Windows 10: Firefox based 2 3205405
>>3202307 →
Бамп.

Мне самому писать или есть с коррекцией перспективы?
Windows 10: New Opera 3 3205465
Надо наложить музыку на картинку, что делать?
Windows 10: Chromium based 4 3205513
>>5465
Шапку читать.
Linux: Firefox based 5 3205534
>>3205329 →

>Не работает ссылка.


Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.

>То это это про битность кодирования отдельных гармоник после косинусного преобразования?


Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.

Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.

>Или про битность RGB->YUV преобразования?


В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.

>Да по идее оно и так в плавающих числах должно производится, чтобы избежать проблем.


Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter

>>3205319 →

>-pix_fmt yuv420p10le


>Что это?


В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
Linux: Firefox based 5 3205534
>>3205329 →

>Не работает ссылка.


Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.

>То это это про битность кодирования отдельных гармоник после косинусного преобразования?


Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был MPEG-2, у которого в профиле Main на уровне Main была опция, позволяющая представлять с большей точностью (10 бит) только коэффициент постоянной составляющей для блока 8×8. Входные и выходные данные при этом представлялись 8-разрядным числом (целым или дробным с фиксированным разделителем, что суть одно и то же). На глаз это должно было повышать качество воспроизводимой последовательности. Рассуждения примерно такие:
- коэффициент постоянной составляющей является результатом вычислений и при его округлении в процессе нормирования при ДКП имеется искажение, дисперсия которого с точностью до постоянного множителя является энергией или мощностью сигнала искажения; так если цена младшего значащего разряда меньше на два двоичных порядка (в 4 раза), то дисперсия, энергия и мощность сигнала искажения уменьшаются в 16 раз;
- уменьшение мощности искажений при вычислении прямого ДКП, обратного ДКП и квантовании коэффициентов ДКП позволит получить более точное восстановление постоянных составляющие в блоках воспроизводимого сигнала, что сделает менее заметной на глаз разность в яркости смежных блоков на тех участках изображение, где эта разность не замаскирована высокочастотными составляющими (например, градиенты большой площади, изображения неба с малым количеством облаков и т. д.);
- в процессе подбора параметра квантования у кодера появляется возможность более точно решить оптимизационную задачу уже при двухкритериальной целевой функции — СКО-подобный (энергетический) показатель искажений восстановленного сигнала и количество информации для представления требуемых элементов в закодированном потоке.

Более обобщим способом для современных кодеров по H.264, H.265 и, возможно (я нормативные документы по AV1, VP8 и VP9 не читал), для других, является режим вычисления и кодирования всех коэффициентов ДКП и отсчётов сигналов как 10- или 12-разрядных чисел. В этой процедуре имеется смысл даже если и исходный материал (например, сканы киноленты или не подвергавшиеся сжатию с потерями изображения с цифровых камер) имеет 8-разрядные отсчёты, и устройство отображения имеет возможность воспроизведения лишь с 8-разрядными отсчётами. И тому есть два аргумента:
- вычисления выполняются с большей точностью, а погрешность округления обеспечивает сигнал искажений только при выводе;
- хранение в потоке данных чисел большей точности снижает эффективность сжатия, но современные кодеры имеют достаточно богатые возможности к решению многокритериальной оптимизационной задачи и найти более устойчивое решение в противоречии между шириной потока и точностью воспроизведения.
Впрочем, я весьма скептически отношусь «пережиманию пережаток» — если исходная последовательность была уже серьёзно искажена при кодировании с потерями, то ошибочно, я считаю, ожидать, что слепое применение 10-битного режима кодирования позволит «ещё немного» повысить эффективность сжатия относительно «весьма незначительного» увеличения искажений.

>Или про битность RGB->YUV преобразования?


В его случае происходить, скорее всего, не должно такого преобразования, т. к. исходная уже в YUV.
О преобразованиях цветовых пространств можно прочесть здесь https://trac.ffmpeg.org/wiki/colorspace
По исходнику libswscale есть пара мест для функций, осуществляющих преобразования между цветовыми пространствами:
https://ffmpeg.org/doxygen/trunk/rgb2rgb__template_8c_source.html#l00649
https://ffmpeg.org/doxygen/trunk/yuv2rgb_8c_source.html#l00048
https://ffmpeg.org/doxygen/trunk/swscale_8c_source.html#l00747
Там внутренние вычисления векторов YUV и RGB ведутся в 32-разрядных типах — int или int32_t. Либо коэффициенты преобразования определены в int32_t, либо к типу int приводится произведение целочисленного отсчёта на коэффициент, определённых десятичной дробью.

>Да по идее оно и так в плавающих числах должно производится, чтобы избежать проблем.


Не в плавающих, а в дробных. И не обязательно с плавающей точкой. Есть варианты в дробных числах с фиксированным разделителем.
Преобразования между пространством RGB и цветоразностными пространствами будут во всех стандартных случаях дробными. Такое положение дел определяется условием нормирования у матриц преобразований:
https://en.wikipedia.org/wiki/Rec._601
https://en.wikipedia.org/wiki/Rec._709
https://en.wikipedia.org/wiki/Rec._2020
https://color.org/chardata/rgb/BT601.xalter
https://color.org/chardata/rgb/BT709.xalter
https://color.org/chardata/rgb/BT2020.xalter

>>3205319 →

>-pix_fmt yuv420p10le


>Что это?


В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
Windows 10: Firefox based 6 3205553
>>5534

>- вычисления выполняются с большей точностью


Не очень понятно почему все промежуточные вычисления не делаются в 32 бита, и только конечное представление ужимается в 8-10 или другое случайное количество бит, где может быть как целое число, так и даже своя шкала, по типу что 0b0001 == 0.001, 0b0010 == 0.003, 0b0011 == 0.007 (которая супер-медленная для промежуточных рассчётов, но чуть эффективнее для сохранения) - как будет короче записать, с обычными числами или сохранив ещё и таблицу для нужного количества бит.
Просто по идее разница между 0 и 1, или 3 и 4 на глаз заметнее, чем разница между 245 и 246, если даже тупо в пеинте одну компоненту поменять, так как яркость заметнее изменяется - потому я и предложил шкалу имеющие шаги ниже ближе к нулю.

>И не обязательно с плавающей точкой.


Да я просто как вариант. Процессор вроде бы одинаково быстро умножает.

>не должно такого преобразования


Точно? То есть оно видя исходные сигналы уже в нужном представлении пережимать их сначала в rgb не будет?
Но такое не сработает, если есть хоть один фильтр что-то делающий с rgb-представлением, и тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера.

Понял в двух словах вроде бы, спасибо.
Linux: Firefox based 7 3205595
>>5553

> Процессор вроде бы одинаково быстро умножает.


Даже самые современные x86_64 работают с целыми разика в полтора быстрее. Плюс умножение и сложений целых и дробных с фиксированным разделителем происходит без потерь, а у дробных с плавающим разделителем с этим ай-ай-ай.

> Не очень понятно почему все промежуточные вычисления не делаются в 32 бита


Потому, что прифит околонулевой, а затраты растут сразу и существенно. В качестве примера предложу тебе в столбик 31 на 42 и 7531 на 8642. Просто держи в уме, что кодер и декодер у нас могут стоять хоть в утюге и быть чисто аппаратными, и требования по минимуму потребляемой энергии отменять никто не будет. А кодер и декодер должны иметь существенную универсальную часть, и для оценки качества должны иметь точно воспроизводимый результат. За последнее при принятии, например, стандарта уже на MPEG-4 ASP H.263 бились (в H.264 уже победили, точно определив универсальный единый для всех реализаций способ вычисления ДКП).

> потому я и предложил шкалу имеющие шаги ниже ближе к нулю


Не могу понять, какая тут связь.

>в нужном представлении пережимать их сначала в rgb не будет?


Если явно не попросишь, то не будет. Соответствующие проверки в коде libswscale есть.

>тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера


Здесь тоже вопрос не понимаю.
Windows 10: Palemoon 8 3205609
>>5595

> Здесь тоже вопрос не понимаю


Это скорее не вопрос, а мысли в слух, никто не может взять в толк почему libjxl входящий в состав ffmpeg не может пережимать jpeg без потерь, как это делает другая реализация энкодера этого формата, а занимается преобразованиями, которые приводят к искажениям. В то время как для libx264, входящий в тот же ffmpeg позволительно сразу работать с yuv
В общем не бери в голову.
изображение.png40 Кб, 577x594
Windows 10: Firefox based 9 3205627
>>5595

>Даже самые современные x86_64 работают с целыми разика в полтора быстрее


Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Причём там же инструкция есть для сложения-умножения для плавающих на 32 и 64, а для целых я такой не вижу.

>Здесь тоже вопрос не понимаю.


Почему libjxl поддерживает перекодирование из jpg без потерь только вне ffmpeg?
Android: Mobile Safari 10 3205717
>>5627

>Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?


Знаешь, ты меня заинтриговал. Я погуглил. Оказалось, что моë мнение ошибочно.
https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
Посоны утверждают, что в зависимости от длины чисел и конкретного камня получается по-разному. Если тебе есть, что сказать, то я бы с удовольствием послушал подробности. По остальным тезисам замечания есть?
Windows 10: Palemoon 11 3205718
>>5717
Я может слепой, но там начиная с хасвеллов инты считаются быстрее, что короткие, что длинные, если это инты, конечно.
Windows 10: Palemoon 12 3205719
>>5718
Кроме деления, но речь про сложение-умножение
Windows 10: Chromium based 13 3205730
>>5384 (OP)
Сжатие медиа - это, конечно, хорошо. Но как на счёт сжатия документов и программ?
Отдаю предпочтение 7-zip с кодеком lzma2 на максимальных настройках. Кто-то скажет, что мейнстрим, но выбирать не из чего. Альтернативы - мутная незадокументированная чепуха, без комьюнити и без бинарников. Которая, к тому же, не может сжимать несколько файлов и папки - то есть сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь в модный архивный кодек. А иногда и выигрыша в степени сжатия нет.
Windows 10: Firefox based 14 3205731
>>5717
Я просто тестил, и операции умножения-сложения на моём ноуте (да и не только на нём, до чего дотянулся) быстрее для float32, чем для целых чисел. Даже без simd.
Медленнее, только если упирается в скорость памяти, и условно говоря целые числа влезают в кеш, а флоаты - нет.

Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.

>>5719
Деление вообще хуета неоптимизированная, но оно и не используется в кучи вычислительных задач. Как впрочем и тригонометрия, где тебе перемножать коэффициенты в разы быстрее, чем складывать углы и считать синус-косинус заново, и в кучи задач тригонометрию можно на что-то заменить.

>>5730
Можешь диск в оперативке сделать, и тар на нём размешать.

>Но как на счёт сжатия документов и программ?


Всё плохо, сжимать с потерями нельзя, потому хотя бы немного неупорядочненную информацию сжать нельзя. Программы не сжимаются, документы, только если формат текстовый, в противном случае едва ли даже 20% получишь. А если там хоть одна картинка в документе, то смысл теряется.
Windows 10: New Opera 15 3205743
Всегда казалось что ffmpeg это какая-то сложная фигня, которую я никогда не осилю, а вот сегодня таки попробовал поделать вебмок, и на удивление всё оказалось легко и просто.
Кстати, в ffmpeg можно монтировать видосы как в Адоб премьере, или такая себе затея?
photo2022-04-1316-34-51.jpg162 Кб, 1062x1080
Windows 10: Palemoon 16 3205754
>>5743

>можно монтировать видосы


Разрешаю.

> такая себе затея


Это.
Linux: Firefox based 17 3205793
>>5743
Ну, она сложная, если ты, как пердолики сверху, будешь ебаться с битностью, хуитностью и прочими параметрами, которые нам, простым домозяйкам, непонятны. А на базовом уровне это обычная консольная утилита - скормил аргументы в нужном порядке и получил профит. Изи ту лёрн, хард ту мастер.
Linux: Firefox based 18 3205836
>>5730

> сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь


И упаковываешь их в tar. И теребишь им bzip2.
А что, перенаправление ввода-вывода отменили уже?

>>5718
Насколько я понимаю результаты, суть в том, что целые и дробные числа числодробят у Штеуда разные процессоры, разрабатываемые разными командами. И коммерческие камни компонуются из наиболее отработанного на момент выхода решения, плюс ограничения ввода-вывода, которые даёт память и её контроллер.

>>5731

>Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.


Есть монография «Recent Advances in Multimedia Signal Processing and Communications» Растислава Лукача. Номерок в libgen — 651313.
Там есть первая же заметка «Color in Multimedia» о цвете как ощущении, цветовых моделях и пространствах.

>и тригонометрия


Таблицей берут или в ряд Тейлора же.

>>5743

> ffmpeg это какая-то сложная фигня


Так-то, да. Я её исходники читаю с большим трудом. И не потому, что они написаны плохо. Примерно соглашусь с >>5793.

>>5793

>можно монтировать видосы как в Адоб премьере


Можно, но зачем, когда она для этого, мягко говоря, не приспособлена.

> или такая себе затея?


Очень-очень такая себе. Если есть желание автоматизировать, то есть vapoursynth — нелинейный видеоредактор питоном (в смысле, что он построен как фреймсервер с питоновыми биндами и опускаемой обвязкой — можно сразу на упрощённом питоне писать редактирующий видео сценарий).
Windows 10: Chromium based 19 3205838
>>5730
Ты ошибся тредом.
Android: Mobile Safari 20 3205860
>>5836

>целые и дробные числа числодробят у Штеуда разные


Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
Linux: Firefox based 21 3205886
>>5860
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
Android: Mobile Safari 22 3205904
>>5886
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
image.png1 Мб, 1600x1000
Android: Firefox based 23 3205926
Исходник: png
Lossy: avif или jpeg xl?
Lossless: avif или jpeg xl?
Android: Firefox based 24 3205927
Что лучше?
Linux: Firefox based 25 3205946
>>5926
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
Android: Firefox based 26 3205954
>>5946
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
Linux: Firefox based 27 3205994
>>5954
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
Linux: Firefox based 28 3206001
>>5954
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.

Выбирай JPEG XL если тебе нужно равномерно размазать битрейт по всей картинке.

Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
Windows 10: Palemoon 29 3206002
>>5994
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
Android: Mobile Safari 30 3206615
Почему, если на двач загружаешь vp8/9, вложенное в mp4, то по ссылке оно все равно переименовывается как webm? Там не V_VP9, а vp09. С av1 тоже самое, av01 по ссылке открывается с .webm
Android: Mobile Safari 31 3206616
К слову, hevc работает в хром, мысли?
Android: Firefox based 32 3206677
Чё там с вебп2?
Windows 10: Chromium based 33 3206688
16626856417970.png87 Кб, 300x300
Android: Mobile Safari 34 3208138
ути-пути, вредина какая
Windows 10: Firefox based 35 3208229
Двачик, что мне делать с 10-и битным видео? Как перекодировать в 264-й, чтобы сохранить качество?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
Linux: Firefox based 36 3208248
>>8229
Ты ебанулся, BDRip транскодить?
Windows 10: Firefox based 37 3208257
>>8248
Мой плеер не поддерживает 10 бит формат. Объясни, в чем я не прав.
Windows 10: Chromium based 38 3208259
>>8257
В том, что пользуешься этим плеером.
Linux: Firefox based 39 3208261
>>8257

> качать 10-bit рипы в H264


У тебя для этого H265 есть. H264 должен быть 8-bit, и точка.
Windows 10: Chromium based 40 3208277
>>8261

>H264 должен быть 8-bit, и точка.


Ты скозал?
Windows 10: Firefox based 41 3208298
>>8259
Не по существу ответ.

>>8261
Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.
Windows 10: Chromium based 42 3208325
>>8298

>Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.


Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
Linux: Firefox based 43 3208390
>>8325
Да не в инет, у него плеер древний. H264 поддерживает, а H265 уже нет.
Windows 10: Chromium based 44 3208405
>>8390

>у него плеер древний


Врятли это причина. Пускай h264 рип качает тогда.
Linux: Firefox based 45 3208419
>>8405
Так это и есть H264, но неправильный, 10-битный. Почему он сам не додумался скачать нормальный рип или ремукс, ума не приложу.
16498481847760.jpg109 Кб, 1080x1080
Windows 10: Palemoon 46 3208453
Почему он просто не посмотрел в интернете
Android: Mobile Safari 47 3208517
>>8229
ffmpeg -c:v libx264 -pix_fmt yuv420p
Windows 10: Firefox based 48 3208560
>>8419

>не додумался


Потому что я еблан и я это признаю. На своем же скриншоте >>8229 не разглядел h264, охуеть я баран. Но от моего самобичевания лучше не станет, поэтому к теме.
Все дело в том, что я положил кучу сил на сборку конкретно этого релиза, но по какой-то странной причине не обратил внимания на битность видео, ебать релизеров в сраку. Я своими руками собирал дорожки с озвучкой и клеил их, а в итоге обнаружил, что встроенный в 11-е окна плеер не может его показать и я не сразу понял, что к чему. Да, забыл сказать для чего это все. Я никуда не выкладываю, просто хотел в коллекцию, то есть длясибя.
Короче что проще - скачать нормальный рип и заново приклеить озвучки или все же можно перекодировать видео в уже готовом контейнере?

>>8517
Храни тебя бог анон, но я вот уже сам начал сомневаться, что пережимать рип норм затея.
Linux: Firefox based 49 3208578
>>8560
Смотри, у тебя есть 2 пути, и оба ведут к торрент-трекеру.

Если для тебя установка сторонних софтовых плееров по какой-то причине неприемлима — качай рип.

Если ты хочешь сам пережать видео и ты знаешь как ты это будешь делать — качай ремукс или BluRay/DVD.

Если имеешь дело с WEB, пережатие скорее всего не требуеться, убедись только что у тебя формат видеодорожки H264 8bit а не H265 10bit HDR DolbyVision.
Windows 10: Firefox based 50 3208639
>>8578
То есть вариант с еблей мы даже не рассматриваем, окей. Ладно, я все понял. Есть еще вопрос: зачем и нахуя люди пилят 10 бит видео? Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой. У меня пиздатый моник, не хдр конечно и не 10 бит, но у большинства людей с торрентов тоже не одиссей джи 9 или че там щас в тренде. И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
16525926709290.png526 Кб, 740x677
Windows 10: Palemoon 51 3208640
>>8639

> То есть вариант с еблей мы даже не рассматриваем


Второй вариант это и есть вариант с еблей, где ты берёшь исходник лучшего какчества и уродуешь. Не рассматривается вариант пожатия пожатого.
Windows 10: Chromium based 52 3208644
>>8639
Цвета лучше, сжатие лучше. Дебандинг.
16632559322870s.jpg8 Кб, 250x250
Linux: Firefox based 53 3208649
>>8560

> скочал нормальный 10-ти битный рип


> гавна встроенная в гавну не поддерживает нормальный 10-ти битный рип


> надо угандошивать нормальный 10-ти битный рип пережатием в менее сжимаемый 8-ми битный чтобы гавна встроенная в гавну поддерживала

Linux: Firefox based 54 3208652
>>8639

> Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой.


Разница есть. С 8-бит в темных сценах аниме ебаные круги бандинга.
И в hi10p не тратится битрейт на борьбу с этим бандингом или чем-то другим, так что энкодер может либо сделать поменьше вес видео, либо улучшить качество с тем же весом.

> И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?


Зачем - ответ выше, бандинг и сжатие. А почему - потому что могут.
Те аниме видео обычно смотрят с субтитрами. И не .srt, а .ass с оформлением. Так что требования к плеерам уже повышены. И т.к. смотрели на пк/ноутах, а не железных плеерах, то наличие аппаратного декодирования не было критичным, процы могли справиться софтверно с hd/fhd и 2-3к битрейтом. Энкодеры решили зафорсить 10бит с 2011, и это прошло относительно безболезненно, зрители обновили плееры и продолжили смотреть.

Видели шутки, которые не шутки, про то что порно индустрия много раз первой осваивала и распространяла новую технологию? Вот с аниме по сути похожая ситуация тогда произошла.
Как сейчас не знаю. Кто-то энкодит пиратство в h.265 или AV1?
Windows 10: Palemoon 55 3208656
>>8652

> Кто-то энкодит пиратство в h.265 или AV1


Анимешники и энкодят, даже тестировали fate'вым касанием небес процессорный декод av1 в райзентреде.
Windows 10: Firefox based 56 3208666
>>8640

>и уродуешь


Ну зачем ты так..

>>8652
Доводы разумные и звучит все круто. Не круто, когда ты мультики не смотришь (за редким исключением) и при случае попадаешь вот в такие ситуации. Ну бывает. Большое тебе спасибо.

>>8649
Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв. Как ты узнал?
Linux: Firefox based 57 3208679
>>8666

> Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв.


То есть кроме стокового и MPV ничего нет? А как же MPC, тот же "потный даун", ну или VLC в конце концов? Мне казалось что этих плееров у вас там хоть жопой жуй, и выбирать можно по симпатичности GUI и нескучным обоям.
Android: Mobile Safari 58 3208829
сап сосака
Хочу перекодировать видео в вебм, но 1. чтоб видео, которые разрешением больше указанного, сжимались в габаритах, 2. чтоб они не растягивались.

К примеру, есть много файлов в 4К, и их надо довести до 720р / или же файлы 4000х4000, и их тоже надо уменьшить, допустим до 500х500.

Как делать?
Diona-(Genshin-Impact)-Genshin-Impact-фэндомы-6754735.jpeg34 Кб, 405x764
Windows 10: Palemoon 59 3208839
Windows 10: Chromium based 60 3208851
>>8829
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
Windows 10: Firefox based 61 3208856
>>5384 (OP)
Моя команда для кодирование в 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" -map 0:a:0 -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 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.

echo и time нужны для удобства - знать, когда я начал и закончил кодировать.

Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Windows 10: Firefox based 61 3208856
>>5384 (OP)
Моя команда для кодирование в 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" -map 0:a:0 -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 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.

echo и time нужны для удобства - знать, когда я начал и закончил кодировать.

Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Windows 7: Firefox based 62 3208891
>>8856

> дополнительный аудиодорожки проебываются


> встроенные сабы проебываются


> метаинфо проебывается


> ненужно1кодек


говно/10
Android: Mobile Safari 63 3208894
>>8856

> Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.


Нихуя подобного

> -strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.


Не нужно давно, это для ффмпег раньше только
Linux: Firefox based 64 3208899
>>8851
Открывает у меня.
Windows 10: Chromium based 65 3209059
>>8856

>Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.


В чем проблема выставить не в секундах?

>Нихуя подобного


Вообще-то он прав. Выставить в секундах можно в av1enc. В ffmpeg ставить только по старому, значением.
Windows 10: Firefox based 66 3209074
>>8891

>> дополнительный аудиодорожки проебываются


Озвучки мне не нужны, но они обычно отдельным файлом лежат. Комментарии от создателей на японском мне тоже не нужны. Остаются дорожки в 5.1 или стерео варианте, какая лучше звучит - ту и выбираю. Всё это время выбирал стерео (в тех релизах другой не было).

>> встроенные сабы проебываются


Делаю их внешними дополнительной командой. Внешние лучше по факту.

>> метаинфо проебывается


Какие метаданные могут быть в видеофайлах? Прогнал сейчас через ffprobe - ничего кроме encoder, creation time и очевидных заголовков ("rus subs", "flac") не нашёл. Могу добавить ещё одну команду, чтоб записывать метаданные в .txt и потом импортировать.

> ненужно1кодек


Сжимает лучше x265, разве нет?

>>8894

>Нихуя подобного


В документации к svt-av1 сказано, что --keyint в секундах только в их официальной программе https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md

>GOP size (frames), use s suffix for seconds (SvtAv1EncApp only) [-2: ~5 seconds, -1: "infinite" only for CRF, 0: == -1]


Вообще, отдельный энкодер лучше комбайна, как минимум в теории.

>>9059

>В чем проблема выставить не в секундах?


Не знаю. Когда читал, забыл видимо, что в секунде всегда одинаковое количество кадров.
Windows 7: Firefox based 67 3209088
>>9074

> Сжимает лучше x265, разве нет?


Нет? позиционировался и продолжает как улучшение x264. Да, лучше чем x264. x265 - нет, в лучшем случае на уровне. И уж точно в разы медленней и ресурсоемче.

>


Чего тогда рейт реквестируешь если сугубо для твоих хотелок и задач однострочник?
Windows 10: Chromium based 68 3209094
>>9074

>Вообще, отдельный энкодер лучше комбайна, как минимум в теории.


По сути не лучше, потому что в ffmpeg есть встроенные плюшки по типу фильтров, скэйлингов и прочего. А параметры самого энкодера легко вписываются в -svtav1-params.
Linux: Firefox based 69 3209100
>>9088

> Нет? позиционировался и продолжает как улучшение x264.


Ты имел в виду VP9?
Ну так-то он чуть лучше HEVC, но ты попробуй заведи HEVC в хроме или фуррифоксе.
Android: Mobile Safari 70 3209102
>>9074
Ичо что там сказано, есть параметр --svt-params keyint:10s вроде в прошлый раз работало. Пайпинг это полнейшая хуйня всегда
Windows 10: Chromium based 71 3209104
>>9100

>Ну так-то он чуть лучше HEVC


Cфигали?
Linux: Firefox based 72 3209113
>>9104
Ну в смысле не VP9 а AV1.

А VP9 да, это конкурент H264, с вразы более медленным временем кодирования чем x264, ненужный нигде кроме кодирования на low-end битрейтах.
Windows 10: Firefox based 73 3209120
>>9104
По факту же, если скорость кодирования не учитывать.
Даже дефолтный средний vp9 самый тяжелый hevc вроде как обгоняет...
Linux: Firefox based 74 3209124
>>9120
Сравнивать надо не --cpu-used 6 с --preset placebo, а качество изображения, полученное за одинаковое время кадра.
Windows 10: Firefox based 75 3209126
>>9102

>Пайпинг это полнейшая хуйня всегда


Почему? Неудобно может быть, согласен - команды длинные. И если команду нужно встроить куда-то, то вообще не вариант.
Windows 10: Firefox based 76 3209132
>>9124

> полученное за одинаковое время


Тогда победит h264 и svt, если время малое, и что-то потяжелея, если время больше.
Windows 10: Chromium based 77 3209133
>>8560

>встроенный в 11-е окна плеер


Нахуй идет, ставишь кодек лайт (внутри MPC) или Potplayer
Windows 10: Firefox based 78 3209158
>>9133

>кодек лайт (внутри MPC) или Potplayer


Нахуй идет, ставишь mpv.
Android: Mobile Safari 79 3209170
>>9126
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Android: Mobile Safari 80 3209171
>>9158
Fix Mpc-be
* Mpc-qt
svt-av1 vs x265 Windows 10: Firefox based 81 3209233
Кодировал один и тот же исходник хорошего качества в svt-av1, а затем в x265. Окончания x265 так и не дождался, завершил на 61 секунде из 1401 всего видео.

Команда для x265:
ffmpeg -i EP01.mkv -map 0:v:0 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 "av1-vs-x265\EP01-x265.mkv"

Команда для svt-av1:
ffmpeg -i "EP01.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 "!svtav1\EP01.ivf"

Кодировал вместе со звуком, но для чистоты эксперимента извлёк из mkv отдельно видео-дорожку:
x265 длительностью 61 секунда весит 157 812 Кб
av1 длительностью 1401 секунда весит 768 933 Кб
То есть разница в 4.713 раза в пользу av1

x265 кодировал 61 секунду за 24 минуты. svt-av1 кодировал 1401 секунду за 130-140 минут.

Качество одинаковое, но в x265 намного больше шума (зерна), примерно столько же, сколько и в исходнике. svt-av1 аккуратно почистил шум.

Вердикт: svt-av1 лучше по качеству, сжимает быстрее и сильнее, чем x265.
Windows 10: Chromium based 82 3209238
>>9233
вердикт говно, потому что надо кодировать одинаковую длительность.
Windows 7: Firefox based 83 3209239
>>9233

> SVT-AV1


Теперь покажи это свое квадратомыльце.
Windows 7: Firefox based 84 3209246
>>9239
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
Windows 10: Firefox based 85 3209257
>>9238
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-ss 70 -t 45), вот что вышло:

ffmpeg -i "EP01.mkv" -map 0:v:0 -ss 70 -t 45 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"
ffmpeg -i EP01.mkv -map 0:v:0 -ss 70 -t 45 -c:v libx265 -crf 19 -preset slower -tune grain -pix_fmt yuv420p10le -bf 16 -x265-params "keyint=24" "av1-vs-x265\EP01-x265-keyint.mkv"

>>9239
>>9246
Квадратов и мыла нет. Если не считать мылом области без сложных текстур, где в оригинале было много шума, а av1 его убрал и дофантазировал на месте шума какое-то мыльцо.

Но потери деталей имеются - на моих скриншотах видно, как в оригинале на лбу красного мехи четыре точки, и от точек в центр уходят слабо прорисованные полосы. av1 почти полностью убрал их. Но в других кадрах рядом они видны. Анимепроблемы, наверное. Но x265 сохранил эти полосы

Что же по времени и весу:
x265 - 16 минут, 127 129 Кб
av1 - 5 минут, 31 350 Кб

Заметил ещё одну очень странную вещь - если указать x265 "keyint=24", то вес файла уменьшится. Без этой опции 131 868 Кб, и ключевые кадры расставлены раз в 12 секунд по моим наблюдениям. Хотя должно быть ровно наоборот - больше ключевых кадров = больше вес файла.
source.png10,2 Мб, 3840x2160
Windows 10: Firefox based 86 3209259
>>9257
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
Android: Mobile Safari 87 3209261
>>9233
Сука, не надо использовать пресет slower. Slow наиболее оптимальный.
Windows 10: Firefox based 88 3209269
>>9261
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
Windows 10: Chromium based 89 3209270
>>9257
av1 видно мылит, детали теряются.
Windows 10: Chromium based 90 3209272
>>9269
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
image.png1,2 Мб, 1280x767
Windows 10: Palemoon 91 3209283
>>9269

> mfw мыльцонство шума выставляется как что-то хорошее

Windows 10: Firefox based 92 3209305
>>9270
Да, посмотрел на другую часть картинки и заметил.
Как же тогда сжимать видео, чтобы без потери деталей?
Linux: Firefox based 93 3209337
>>9305
x264 на 10 мегабит и не мучайся.
Windows 10: Firefox based 94 3209339
>>9337
Толсто. Такой транскод только увеличит размер файлов.
Linux: Firefox based 95 3209344
>>9339
Отлично. Значит ничего пережимать и не надо. Оставляй оригинал как есть.
Windows 10: Firefox based 96 3209345
>>9344
Зачем тогда этот тред нужен, если здесь предлагают "оставить как есть" и "раздуть до 10 мбит/с"?
1530823796245.webm19,8 Мб, webm,
320x180, 127:23
Windows 10: Chromium based 97 3209347
>>9345
Это залётыши. Тру юзеры ффмпега смотрят фильмы только так.
Windows 10: Firefox based 98 3209353
>>9347
Шакал Квадратович, добро пожаловать!
Windows 10: Firefox based 99 3209386
>>9347
А может кто-то загрузить и через svt такое сделать на 20 мб, для теста?
У меня просто мобилка, 200 кбит/с.
Linux: Firefox based 100 3209405
Есть ли толк перегонять AVC в HEVC ради уменьшения размера (с допустимой незначительной потерей качества)? Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
Windows 7: Firefox based 101 3209416
>>9257
>>9259
Чет дофига "додумало" в av1. Это как с говнофильтрами "улучшаторами" смотреть. Ну такое.
Тут более-менее смотрится, полно однотонных участков. А на динамичных и прегруженых деталями (листва) сценах изрядная дрисня вероятно будет получаться.
Windows 10: Firefox based 102 3209434
>>9416

>изрядная дрисня вероятно будет получаться


Вероятно. По идее от битрейта зависит, а битрейт динамически выставляется crf - чем загруженнее сцена, тем больше на неё битрейт.
Надеюсь, что всё-таки проблема тех скриншотов из-за чрезмерного шума, и в современных тайтлах, где шума нет, или незначительно мало, svtav1 будет кодировать намного лучше. За сегодняшний день я изрядно огорчился в способностях кодеков, думал, сожму раз эдак в 6 без видимых глазу потерь, но нет. Хотя с предыдущим тайтлом получилось сжать без видимых потерь, или может я слишком мало сцен там сравнивал.
Windows 10: Firefox based 103 3209436
>>9434
>>9416
Вашему вниманию скриншоты того самого тайтла с меньшим шумом.
Windows 10: Firefox based 104 3209443
>>5384 (OP)

> ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.


О каком "баттле" может идти речь, если VVC не поддерживается в mpv, только в васянской сборке https://github.com/MartinEesmaa/VVCEasy ? В других плеерах тоже не поддерживается, только через мокрописи-дополнения. И в ffmpeg его нет. Хуйня сырая в общем, ждём.
Windows 7: Firefox based 105 3209447
>>9436
Как на счет каких-нибудь ИРЛ видосикв с кустиками? Есь чо? Или кинца хоть. Лень качать.
Linux: Firefox based 106 3209462
>>9386
Твоя мобила AV1 не потянет. Только 3GPP в 144p с квадратами на весь экран.
Linux: Firefox based 107 3209463
>>9405

> Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?


Именно.
>>9345
Какой вопрос — такой ответ. Хотите visually lossless — соблюдайте заветы торентоблядей. x264, пердолинг с параметрами на уровне пресета placebo и битрейты как половина от блюрея ждут вас.

Хотите сжатия? Минимального размера при максимальной эффективности? Тогда выбирайте подходящий для вас CRF, устраивающий вас пресет или --cpu-used, и вперёд. И не надо ни у кого спрашивать, какой CRF лучше. Сам сравни и выбери наилучший для тебя.
Windows 10: Firefox based 108 3209464
>>9462
Я не смотрю видео с мобилы.
Android: Mobile Safari 109 3209475
Опять болезные пытаются svt-av1 сравнивать с какой-то хуйней, когда в прошлом тренде уже доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom.
aom.png1 Кб, 768x16
Windows 7: Firefox based 110 3209477
>>9475

> aom

image.png4 Кб, 931x17
Windows 10: Firefox based 111 3209480
Опять криворукие дурачки, не сумевшие в пресеты, вылезли.
Windows 10: Firefox based 112 3209492
trac.ffmpeg.org перестал открываться.
Linux: Firefox based 113 3209493
>>9480
Пресеты с цифрой больше чем 4 не нужны.
Android: Mobile Safari 114 3209499
>>9480
Ох уж этот пресет у долбоеба который выглядит хуже x264 slow
Windows 10: Firefox based 115 3209501
>>9493
>>9499
Пресет 8 в aom выглядит неотличимо от пресета 5 в svt-av1, но svt-av1 кодирует в два раза дольше, чмоньки.
Linux: Firefox based 116 3209509
>>9501
Откуда инфа? Тоже хочу посмотреть.
Windows 10: Firefox based 117 3209512
>>9509
Инфа из прошлого треда.
Windows 10: Firefox based 118 3209513
>>9501

>Пресет 8 в aom


У aom есть пресеты? А что ещё у него есть? Хочу увидеть документацию по всем параметрам.
image-79005-2.jpg163 Кб, 1280x1155
Windows 10: Firefox based 119 3209515
Перепробовал многие кодеки, и пришёл к выводу, что единственный хороший из них - пикрилейтед. В конце своих скитаний и напрасно потраченного времени вы это поймёте.
Windows 10: Firefox based 120 3209516
Windows 10: Firefox based 121 3209517
>>9516
Ну и где там "preset"? Поиск на странице дал 0 результатов, нет там этого слова.

>ffmpeg.org


Не открывается.
1664100147209.png521 Кб, 1200x600
Windows 10: Firefox based 122 3209519
>>9517

>Ну и где там "preset"?

Windows 10: Firefox based 123 3209520
>>9519

>пук



>>9501

>Пресет 8 в aom

1664100761799.png521 Кб, 1200x600
Windows 10: Firefox based 124 3209521
Windows 10: Firefox based 125 3209522
>>9521

>ХРЮК!

Linux: Chromium based 126 3209524
как ускорить кучу мп3-файлов в 2 раза чтобы они не начали пищать как будто гелия надышались?
Linux: Firefox based 127 3209529
>>9520
cpu-used в aomenc
preset в svt-av1

Что непонятного?
Windows 7: Firefox based 128 3209536
>>9515
Хороший кодек. Но я бы предпочитаю кодек WD.
Windows 10: Firefox based 129 3209548
>>9515
А как таким кодеком шебмы на 2ch.hk заливать?
Windows 10: Chromium based 130 3209575
>>9524
обычный спидап, чем еще. -filter:a "atempo=2.0"
Windows 10: Firefox based 131 3209581
Ну что же, давайте подумаем, где какой кодек, и какой из них лучше. Слева сверху, очевидно, сурс. На пикчах одни и те же кодеки расположены одинаково, т.е. справа сверху всегда один и тот же кодек.
Варианты для угадывания:
libsvtav1 c -preset 4
libaom-av1 с -cpu-used 8
libsvtav1 c -preset 5

Ссылка на запароленный архив, в котором содержится информация о том, где какой скрин и какие конкретно команды использовались, а так же затраченное время:
https://litter.catbox.moe/4vdayc.7z

Сегодня в 22:00 по МСК скину пароль. Или завтра, смотря как получится.
Windows 10: Firefox based 132 3209582
>>9581
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
Windows 10: Firefox based 133 3209583
>>9475

>что при одинаковом времени кодирования


При одинаковом времени кодирования aom не работает. Можешь показать при каких настройках aom сможет кодировать 1280х720х60 в реальном времени? Или хотя бы со скоростью 0.5?
16637861174630.jpg452 Кб, 1080x1642
Windows 10: Chromium based 134 3209584
>>9581
>>9581

> давайте подумаем


> libsvtav1 c -preset 4


> libaom-av1 с -cpu-used 8


> libsvtav1 c -preset 5


Чтобы что? Шебмы для двача кодируешь? Да можешь хоть в вп8 делать, а фильмоделы, борцуны за какчество, ждут vvc.
Windows 10: Firefox based 135 3209585
>>9583
Болезный, тебе зачем на процессоре av1 кодировать в реалтайме? Жди хардверных энкодеров на видеокартах, ими и кодируй с большими битрейтами, если до пизды нужно кодировать в ав1. А что же касается непосредственно вопроса, то aom не может кодировать в реалтайме. А то, что кодирует в реалтайме svt - мыло мыльнейшее.
Windows 10: Firefox based 136 3209586
>>9584
Чтобы ты спросил.
Windows 10: Firefox based 137 3209589
>>9585
Меня не интересуют кодеры работающие со скоростью меньше 0.3.
Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.

>мыло мыльнейшее.


Всё ещё лучше реалтаймовых vp9/h264/h265 при том же битрейте.
Windows 10: Chromium based 138 3209590
>>9581

>3


ты хочешь что у людей глаза к хуям вытекли. Пики говно. Нах на мыльном говниме сравнить, тем более без деталей,
Windows 10: Firefox based 139 3209592
>>9590

>Нах на мыльном говниме сравнить, тем более без деталей


Критикуешь - предлагай.
1567824512303.webm5,7 Мб, webm,
480x480, 2:17
Linux: Chromium based 140 3209599
>>9575
спасибо, теперь буду превращать дум-метал в танцевальную музыку.
Linux: Firefox based 141 3209603
>>9581
Ну что, давайте присвоим этим секциям номер, слева-направо сверху-вниз

Про кадр 1: секция 2 пожата наиболее грубо, ставлю на пресет 5. Секция 4 пожата получше, но всё ещё грубо. Ставлю на пресет 4. Лучше всего выглядит как по мне секция 3, ставлю на libaom.

Кадр 2: ты включил Grain syntesis? Но он здесь не нужен. В исходнике нету шумов, только градиенты. Соответственно наиболее выигрышной стратегией будет просто дать ему замылить, может так он сделает градиенты ещё плавнее и удалит наконец этот бандинг.

Кадр 3: в секции 2 я отчётливо вижу артефакты работы такой фишки AV1 как восстановление цвета из яркостного канала. Прям блоки резко меняющихся цветов повылазили. Ничего не изменилось, ставки по прежнему на 5-м пресете.
Между кадром в 4-й и 3-й секции разницы беглым взглядом не вижу. Ставки не меняються, просто как факт что разница не очевидна.

Кадр 4: бандинг, бандинг, бандинг. Везде бандинг кроме исходника. Скажи честно, ты его в 8 бит сжимал? Впрочем, даже если в 10, не удивлюсь. Но с этим бандингом надо бороться. Даже не знаю как это сделать не раздувая битрейт. Я даже сомневаюсь что 12 бит уберет бандинг. Может сгладит границы, и контуры цветовых переходов станут выглядеть аккуратнее, но вот как забороть бандинг насовсем не знаю.
Windows 10: Chromium based 142 3209610
>>9443

> ждём официального исхода баттла VVC vs AV1


> Хуйня сырая в общем, ждём.


Там так и написано..
Windows 10: Chromium based 143 3209614
>>9575
А scaletempo2?
Windows 10: Firefox based 144 3209615
>>9610

> исхода баттла VVC vs AV1


О каком баттле идёт речь? Как всегда, VVC aka H.266 займёт место на 8K HDR блуреях, а AV1 как свободный от патентов на YT/интернет видео. AV1 нужно скорее с H.265 сравнивать, который, к слову, уже внедрили в Сафари и в Хром. Спустя 10 лет может и выкатят кодек, который сопоставим с VVC, но сейчас мощи H.265 избыточны. AV1 как был свободным мыльцом так и останется, не в тот состоянии, чтобы с проприетарными кодеками тягаться.
Windows 10: Chromium based 145 3209616
>>9592
Качественные футажи прогулки по траве.
мимо
Windows 10: Chromium based 146 3209617
>>9615

> ждём


Ждём..
Linux: Firefox based 147 3209619
>>9589

> Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.



У тебя неправильная формула. Стоимость транскодирования определяется по формуле:

стоимость транскодирования = время затраченное на транскодирование / (объём информации * срок хранения информации).

Иначе говоря, если ты хочешь сохранить значительный объём информации на долгий срок, то транскодирование безусловно выгодно.
Например, у тебя есть 200 Гб видео, которое ты хочешь сохранить у себя навсегда. Допустим тебе придётся затратить месяц на транскодирование всех этих видео. Что выгоднее, транскодировать месяц и получить 100 Гб информации заместо 200 Гб, которые ты будешь хранить годами, или таскать с собой все 200 Гб переливая их с одного HDD на другой + регулярные бекапы на чёрный день?
Windows 10: Chromium based 148 3209621
>>9619
При хранении личных видео на года тем более не хочется терять качество.
мимо
Windows 10: Firefox based 149 3209632
>>9603
Ты ещё пятый кадр пропустил, он постом ниже.

>Скажи честно, ты его в 8 бит сжимал?


Да, все видео были сжаты в 8 бит, и на то, что я не пожал в 10 бит, есть несколько причин.

Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.

Вторая заключается в том, что мы сравниваем между собой не исходник с кодеком, а кодек с кодеком. Из этого вытекает, что если битность одинаковая, то разницы по качеству из-за несовпадающей битности в этом случае быть не должно. Но я внутрь не лез, так что это может быть притянуто за уши. Один кодек может утилизировать 10 бит лучше, чем другой. Или наоборот, какой-то кодек лучше себя проявляет именно в 8 бит.

И третья следует из второй, чтобы посмотреть на реальную разницу между 10 бит и 8 бит с разными пресетами и энкодерами, нужно было бы делать ещё больше тестовых картинок, на что ни я, ни файловые лимиты на доске ещё пока не готовы.

>>9616
Увы, у меня таких футажей нет, откуда брать - не знаю, а сервисами со стоками я не пользуюсь.
Linux: Chromium based 150 3209634
если верить сайту амд моя видеокарта поддерживает аппаратное кодирование h265 https://www.amd.com/en/products/graphics/amd-radeon-rx-6600-xt но когда я пытаюсь кодировать получается зелёный экран и наверху какие-то ошмётки от видео. с чем это может быть связано?
Windows 10: Chromium based 151 3209635
>>9634
Это значи амуде говно.
Тут не эктрасенсы сидят, чтобы гадать как чем ты кодировал..
Linux: Firefox based 152 3209636
>>9632

> Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.


Должны, ибо находятся в одном и том-же профиле — стандартном. Лишь для 12 бит нужно активировать high profile.

И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
Обновить тред
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски

Скачать тред только с превьюс превью и прикрепленными файлами

Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах.Подробнее