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
>>05465
Шапку читать.
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
>>05534

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


Не очень понятно почему все промежуточные вычисления не делаются в 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
>>05553

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

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


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

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


Разрешаю.

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


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

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


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

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

>>05731

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


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

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


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

>>05743

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


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

>>05793

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


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

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


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

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


Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
Linux: Firefox based 21 3205886
>>05860
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
Android: Mobile Safari 22 3205904
>>05886
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
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
>>05926
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
Android: Firefox based 26 3205954
>>05946
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
Linux: Firefox based 27 3205994
>>05954
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
Linux: Firefox based 28 3206001
>>05954
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.

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

Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
Windows 10: Palemoon 29 3206002
>>05994
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
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
Windows 10: Firefox based 34 3208229
Двачик, что мне делать с 10-и битным видео? Как перекодировать в 264-й, чтобы сохранить качество?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
Linux: Firefox based 35 3208248
>>08229
Ты ебанулся, BDRip транскодить?
Windows 10: Firefox based 36 3208257
>>08248
Мой плеер не поддерживает 10 бит формат. Объясни, в чем я не прав.
Windows 10: Chromium based 37 3208259
>>08257
В том, что пользуешься этим плеером.
Linux: Firefox based 38 3208261
>>08257

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


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

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


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

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

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


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

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


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

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


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

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

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

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

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

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


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

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


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


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

Linux: Firefox based 53 3208652
>>08639

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


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

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


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

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

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


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

>и уродуешь


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

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

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

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


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

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

Как делать?
Diona-(Genshin-Impact)-Genshin-Impact-фэндомы-6754735.jpeg34 Кб, 405x764
Windows 10: Palemoon 58 3208839
Windows 10: Chromium based 59 3208851
>>08829
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
Windows 10: Firefox based 60 3208856
>>05384 (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 60 3208856
>>05384 (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 61 3208891
>>08856

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


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


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


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


говно/10
Android: Mobile Safari 62 3208894
>>08856

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

>>08894

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


В документации к 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]


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

>>09059

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


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

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


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

>


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

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


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

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


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

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


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

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

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


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

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


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

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


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

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


Нахуй идет, ставишь mpv.
Android: Mobile Safari 78 3209170
>>09126
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Android: Mobile Safari 79 3209171
>>09158
Fix Mpc-be
* Mpc-qt
svt-av1 vs x265 Windows 10: Firefox based 80 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 81 3209238
>>09233
вердикт говно, потому что надо кодировать одинаковую длительность.
Windows 7: Firefox based 82 3209239
>>09233

> SVT-AV1


Теперь покажи это свое квадратомыльце.
Windows 7: Firefox based 83 3209246
>>09239
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
Windows 10: Firefox based 84 3209257
>>09238
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-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"

>>09239
>>09246
Квадратов и мыла нет. Если не считать мылом области без сложных текстур, где в оригинале было много шума, а 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 85 3209259
>>09257
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
Android: Mobile Safari 86 3209261
>>09233
Сука, не надо использовать пресет slower. Slow наиболее оптимальный.
Windows 10: Firefox based 87 3209269
>>09261
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
Windows 10: Chromium based 88 3209270
>>09257
av1 видно мылит, детали теряются.
Windows 10: Chromium based 89 3209272
>>09269
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
image.png1,2 Мб, 1280x767
Windows 10: Palemoon 90 3209283
>>09269

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

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

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


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

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


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

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


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

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

> aom

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

>Пресет 8 в aom


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

>ffmpeg.org


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

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

Windows 10: Firefox based 122 3209520
>>09519

>пук



>>09501

>Пресет 8 в aom

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

>ХРЮК!

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

Что непонятного?
Windows 7: Firefox based 127 3209536
>>09515
Хороший кодек. Но я бы предпочитаю кодек WD.
Windows 10: Firefox based 128 3209548
>>09515
А как таким кодеком шебмы на 2ch.hk заливать?
Windows 10: Chromium based 129 3209575
>>09524
обычный спидап, чем еще. -filter:a "atempo=2.0"
Windows 10: Firefox based 130 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 131 3209582
>>09581
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
Windows 10: Firefox based 132 3209583
>>09475

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


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

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


> libsvtav1 c -preset 4


> libaom-av1 с -cpu-used 8


> libsvtav1 c -preset 5


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

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


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

>3


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

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


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

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

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

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

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

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


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


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

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


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

> ждём


Ждём..
Linux: Firefox based 146 3209619
>>09589

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



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

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

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

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


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

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

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

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

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

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


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

И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
Linux: Firefox based 152 3209653
>>09632
>>09582
Ну значит посмотрел я 5-й кадр. Тут мне 2-й сегмент понравился больше чем четвёртый почему-то. И да, только libaom попытался в чёткость, но получилось у него только то что можно было предсказать, всё остальное тоже мыльное. А у svt мыльное всё.
Windows 10: Firefox based 153 3209656
>>09581
Только один пока решился расписать что-то, видимо придется ждать до завтра.
Windows 10: Firefox based 154 3209662
>>09610
Доколе ждать? Есть примерные сроки, когда выкатят стабильный кодировщик и видеоплееры обзаведутся нужным декодером?

>>09615
По части звука так же - проприетарный aac лучше свободного opus?
Windows 10: Firefox based 155 3209663
>>09662

> aac


Extended HE-AAC лучше.
Linux: Firefox based 156 3209667
>>09663
Когда же декодер добавят в ffmpeg? Кодировать уже есть чем, а декодировать нечем.
Android: Mobile Safari 157 3209697
>>09615

> AV1 нужно скорее с H.265 сравнивать


Откуда такая информация?
Android: Firefox based 158 3209712
>>09663
А если меня не интересуют отчетливые голоса на битрейтах картошки, а интересует сохранность всех слышимых деталей до 20-22 кГц, какой мне кодек звука использовать?
Android: Mobile Safari 159 3209714
>>09712
Wavpack
Android: Firefox based 160 3209719
>>09714
Толсто. Прямо как вес wavpack файлов.
Linux: Firefox based 161 3209730
>>09712
Ну и зачем тебе этот кодек когда он ещё толком ничем не поддерживается?

Есть Opus, есть AAC, есть Vorbis в конце концов. Выбирай любой который тебе больше нравиться.
Windows 10: Chromium based 162 3209736
Раньше тоже ебался с этими кодеками, кодировал там что-то. Потом со временем как начал работать вставил себе несколько терабайт и больше не ебусь с этим.
Windows 10: Chromium based 163 3209737
Че там сча по совместимости с аудиокодеками? Когда конверчу в мп3 то на 100% уверен что смогу воспроизвести везде.

С аас и огг также? Кто из них пизже? Для огг aotuv еще актуален или есть что-то пизже? Или может уже оригинальный libvorbis не хуже?

У опуса я так понял до сих пор плохая совместимость? Что-то круче него не придумали еще?
Linux: Firefox based 164 3209745
>>09737
У AAC почти так-же. AAC не поддерживают только китайские MP3 плееры, китайские наушники с функцией mp3 плеера, ну и какой-нибудь музейный раритет. Даже старые кнопочные телефоны поддерживают AAC LC.

Opus открывается на любом более менее актуальном смартфоне. Если у тебя остался старый едва работающий смартфон на Android 4 и младше, то у тебя есть выбор между AAC и Vorbis.
Android: Firefox based 165 3209747
>>09737

>везде


В пизде.
Обзаведись портативным устройством под бюджет, софтовым плеером на вкус, и будет тебе настоящее везде. Mp3 по факту устарел, ему не место в 2022 году ни под каким соусом. Гоните и насмехайтесь над теми, кто в него сжимает. Не место, так же как и огрызкам, которые ничего современные не поддерживают.
Android: Mobile Safari 166 3209847
>>09719
Что ты высрал, клоун?
У этого кодека очень щадящее сжатие, как раз останутся все частоты
Windows 10: Firefox based 167 3209899
>>09581
Пароль от архива: 0a7DA6B4IjN7R2P28jQ7Tq0u52B2BeJF
Всем прочитавшим, но проигнорировавшим чмоням желаю плохих снов. Получилась отличная выборка из одного человека. Дублирую для самых ленивых (почти всех) содержание архива:

Слева сверху оригинал.
Справа сверху libaom-av1 с -cpu-used 8
Слева снизу libsvtav1 c -preset 4
Справа снизу libsvtav1 с -preset 5
Изображение с лицом - контрольное, оно не сжималось кодеками, все 3 картинки шакалились с помощью одних и тех же фильтров фотошопа.

libaom-av1 с -cpu-used 8 кодировался 06:29
libsvtav1 c -preset 4 кодировался 11:49
libsvtav1 c -preset 5 кодировался 06:07

Полные команды:
ffmpeg -hide_banner -i in.mkv -pass 1 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -an -f null nul
ffmpeg -hide_banner -i in.mkv -pass 2 -passlogfile passlog -c:v libaom-av1 -cpu-used 8 -tile-columns 4 -b:v 488.3k -threads 16 -auto-alt-ref 1 -lag-in-frames 25 -g 128 -c:a libopus -b:a 128k libaom-av1-8.webm

ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 4 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-4.webm

ffmpeg -hide_banner -i in.mkv -c:v libsvtav1 -preset 5 -g 128 -b:v 488.3k -c:a libopus -b:a 128k libsvtav1-5.webm
16492558823400.png278 Кб, 640x578
Windows 10: Palemoon 168 3209902
Windows 10: Firefox based 169 3209903
>>09899
А нахуя архив, если ты команды скинул?
Linux: Firefox based 170 3209926
>>09899
То есть я не угадал ни в одном из случаев.

Худшим оказался libaom с cpu-used 8. Отличное разоблачение мифа, однако.

Лучшим оказался svt1av1 с пресетом 4, что в общем то логично. Кстати, нужно сравнить svtav1 preset 4 с aomenc cpu-used 4 запущенным через av1an.
Windows 10: Firefox based 171 3209985
>>09714
Чем он лучше опуса?
Windows 10: Chromium based 172 3210111
Я не пойму vvc вышел или нет, можно в него покодировать, какая производительность? Пока что компилирую и посмотрю что да как.
Windows 10: Firefox based 173 3210116
>>10111

>можно в него покодировать


Кодировать можно, а декодировать - хуй. Поэтому

>Я не пойму vvc вышел или нет


Нет, не вышел.
Windows 10: Chromium based 174 3210121
>>10116

>Кодировать можно, а декодировать - хуй. Поэтому


Да ну. Есть же софтверный плеер какой-нибудь. Хотя пока в ffmpeg не запихнут, так и не будет наверное. Потому что почти все плееры юзают ffmpeg.

>Нет, не вышел.


Посмотрел, вышел то еще в 2020 по сути. https://github.com/fraunhoferhhi/vvenc. Уже версия 1.6.
Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
Windows 10: Firefox based 175 3210122
>>10121

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


"Какой-нибудь" - ключевое слово. По факту никакой. Ни mpv, ни ffmpeg, ни конусы и дауны, вангую, тоже.

>Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.


А потом что? Чем открывать будешь?
Windows 10: Chromium based 176 3210125
>>10122
vlc плагин какой-то есть https://code.videolan.org/videolan/vlc/-/issues/27055
но у меня не получается его завести
есть еще tencent O266, но мне лень компилить сурс с помощью докера.
Беда прям какая-то, за 2 года могли и допилить.
Windows 10: Palemoon 177 3210126
>>10125
Куда спешишь? Расслабься, не уйдёт от тебя нескодированное видео, скодируешь, когда будут декодеры.
mXnxOtBRrW.png79 Кб, 1278x498
Windows 10: Chromium based 178 3210129
>>10126
Так я уже скодировал. 2 секунды в 60 фпс, 210 фреймов. Судя по гитхабу пресет slow чуть медленнее пресета x265 placebo. В общем, у них там работа ведется, и кодек реально очень хорошо оптимизируется, в сравнении с прошлыми версиями.
Можно сбилдить vlc с поддержкой vvdec, но снова лень чет разворачивать всё.
Windows 10: Firefox based 179 3210130
>>10129
Когда завезут поддержку в mpv?
Windows 10: Chromium based 180 3210139
>>10130
хз скомпилить самому с libvvdec
image.png25 Кб, 435x92
Linux: Firefox based 181 3210169

> If you read the VVenC line across, you see that VVenC delivered a 39% efficiency gain over x265, which is in line with the test model and impressive, but was only 11% more efficient than AV1.



Ну и кому нужен такой кодек? Гуглу такой кодек точно не нужен. Есть варианты?
Windows 10: Firefox based 182 3210171
>>10169
Получается, что av1 эффективнее x265? Ну, по личным наблюдениям, транскод в x265 даёт очень хорошую сохранность деталям при небольшом уменьшении размера, а av1, как ты не пыхти, будет мылом, но весит мало. Хотя в некоторых сценах и с некоторым материалом av1 не показывает никакой потери деталей, только убирает шум (шум=избыточность).
Linux: Firefox based 183 3210182
>>10171
x265 выглядит чётче потому-что там предусмотрены специальные психовизуальные оптимизации которые увеличивают погрешность при кодировании, но улучшают восприятие картинки. Мне эти оптимизации уже выходили боком, когда я кодировал плавные градиенты на тёмном фоне, они превращались в блочно пиксельное нечто — пришлось вручную уменьшать psy-rd.

У aomenc с этими техниками беда — он по дефолту тюнит под PSNR, а с другими метриками у него какие-то непонятки: то их надо включать в билд, то они замедляют кодирование… Говорят есть ещё форк psyaom, не помню как именно он назывался, но мне лень пердолиться с ним, тем более что меня и ванильный aomenc устраивает.
Windows 10: Palemoon 184 3210183
>>10169
Что это за пиздец? На каком разрешении, на каких скоростях и прочая и прочая

> Ну и кому нужен такой кодек


А кому нужно что-то выше h264? Тем, у кого проблемки с шириной канала(ограничение на размер прикрепа в посте)/сверхвысокие разрешения, в которых h264 не эффективен, ввиду малого размера блоков, для 1080p это всё пустое баловство и 60% большей эффективности, при сравнимом качестве и адекватном битрейте там наберётся едва ли.
Windows 10: Chromium based 185 3210187
>>10169
Что vp9, что av1 мылит я ебал. Даже в 4:4:4 деталей не остается, в сравнении с x264.
Windows 10: Chromium based 186 3210188
>>10169
ссылку откула взял вдруг версии энкодеров старые.
Windows 10: Palemoon 187 3210189
>>10187

>мылит я ебал


Таков путь!
Windows 10: Chromium based 189 3210193
>>10191
чел это тесты с декабря 20 года, после 2-3 месяцов выхода vvc.
https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance
Windows 10: Firefox based 190 3210196
>>10182
Про психовизуальное восприятие не знал. Градиенты не кодировал, сказать не могу.

>он по дефолту тюнит под PSNR


PSNR весит чуть меньше, но на глаз ощутимо хуже чем VQ (--tune 0). Я ещё удивился, почему его по дефолту не ставят.

>а с другими метриками


метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.

>то они замедляют кодирование


Разве?

>Говорят есть ещё форк psyaom


Не слышал о таком. Малопопулярные форки доставляют много проблем - мало кто ловит ошибки в них и проводит тесты.
Linux: Firefox based 191 3210198
>>10196

> метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.


Я про aomenc, если что.
Windows 10: Firefox based 192 3210199
>>10198
Есть полный список метрик?
image.png7 Кб, 1050x47
Linux: Firefox based 193 3210205
Windows 10: Chromium based 194 3211086
>>05384 (OP)

> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md


> CQ и остальные выглядят хуже потому что предназначены для другого и поэтому не рекомендуются!


Для чего они предназначены?
Windows 10: Chromium based 196 3211156
>>11108
Если crf повышает значение в динамичных сценах, то почему в них наоборот выше битрейт, чем в статичных?
Linux: Firefox based 197 3211161
>>11156
Потому что если повышать ещё сильнее — картинка посыпется на квадраты.
Windows 10: Chromium based 198 3211198
>>11161
Но ведь можно просто не повышать.
Linux: Firefox based 199 3211214
>>11198
Тогда это будет режим с постоянным квантователем, и весить такой файл будет больше.
Windows 10: Chromium based 200 3211217
>>05384 (OP)

> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md


> Указаны два параметра которые рекомендуются в руководстве для повышения качества видео.


Ты сам разбирался, что они значат, или просто на авторитетный источник ссылаешься (он не открывается, кстати)? Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше при прочих равных. По качеству никакой разницы, всё равно CRF 35.
Android: Mobile Safari 201 3211228
>>11217
В смысле не открывается
Ну да, ссылаюсь. Параметры из документаций официальных набирал, и по опыту.

> Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше


Серьёзно, можешь показать пример? Странно
Linux: Chromium based 202 3211324
можно ли сделать красивый плейлист в виде

Album
[04:20] 1. Artist - Song

с помощью ffprobe или ffmpeg?
Linux: Firefox based 203 3211325
>>11324
Проще вручную m3u плейлист в блокноте написать.
Linux: Chromium based 204 3211326
>>11325
не, нужен именно текстовый список для оформления раздачи на рутрекере.
Linux: Firefox based 205 3211327
>>11326
ХЗ. Тут с регулярками баловаться надо, а где и как это делать что-бы получить текстовик не знаю.
Android: Mobile Safari 206 3211352
>>11324
https://trac.ffmpeg.org/wiki/FFprobeTips
Твой sed, awk? -show_entries, скрипт на баше?
Windows 7: Firefox based 207 3211361
>>3199130 →

> но там был патч



Да не было там ни хуя.

(Или покажи, где он был.)

>>3201419 →

> А это разве и не значит, что разница между исходным видео и полученным будет не выше определённой?



Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.

Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).

>>3201460 →

> Кстати, это нормально, что оно



Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.

>>3201691 →

> JPEG XL ещё эффективнее



Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).

Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.

>>3201703 →

> на катастрофически низком битрейте



Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.

(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.

Квадратики макроблоков кодирования также становятся раздражающе видными.)

>>3201850 →

> Гугл не ищет.



Google воспринимает минус перед словом как оператор отрицания.

(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)

>>3202778 →

> вменяемый просмотрщик изображений с поддержкой JXL



XnView MP

>>3205312 →

> Что думаете о моей команде для кодирования в SVT-AV1?



Поясните, почему нельзя было вызвать FFmpeg один раз?

ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"

Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.

Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.

>>08639

> зачем и нахуя люди пилят 10 бит видео?



>>3205319 →

> Что такое 10 бит с математическо-программистической точки зрения?



Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.

(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)

Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)

Вот как это устроено:

① Всякое видеокодирование происходит с внесением потерь в кадры.

② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.

③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).

④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.

⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.

⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.

Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:

⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).

⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).

Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.

>>08560

> встроенный в 11-е окна плеер не может его показать



Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).

>>09059

> В ffmpeg ставить только по-старому, значением.



Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».

Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.

>>09102

> keyint:10s



Не «:», а «=».

>>09133

> ставишь кодек лайт



Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.

>>09475

> доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom



У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.

Но эти новости и кого угодно порадуют.

По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.

>>09667

> Когда же декодер добавят в FFmpeg?



Когда закончится срок дѣйствія патента.

Ждём до ≈2032 года.
Windows 7: Firefox based 207 3211361
>>3199130 →

> но там был патч



Да не было там ни хуя.

(Или покажи, где он был.)

>>3201419 →

> А это разве и не значит, что разница между исходным видео и полученным будет не выше определённой?



Значит, но при определённом (не слишком сложном) подсчёте разницы, который ограничивается чистым вычитанием.

Поэтому опора на этот метод при видеосжатии даёт результаты похуже тѣхъ, которые пытаются считать ещё реальную замѣтность разницы (которая зависит не только от ея величины).

>>3201460 →

> Кстати, это нормально, что оно



Не нормально; но ужé, к нашему счастью, было исправлено разработчиками.

>>3201691 →

> JPEG XL ещё эффективнее



Работу кодировщика lossless JPEG XL разработчики ещё не довели до такого уровня, чтобы он ВСЕГДА опережал lossless WebP (хотя теоретически такое ≈возможно).

Поэтому после перекодирования ещё провѣряйте, не распух ли файл по объёму.

>>3201703 →

> на катастрофически низком битрейте



Думаю, что на катастрофически низком битрейте AVIF чуточку лучше выглядит.

(JPEG XL начинает «извилисто ломать» косые отрѣзки линий, напримѣръ.

Квадратики макроблоков кодирования также становятся раздражающе видными.)

>>3201850 →

> Гугл не ищет.



Google воспринимает минус перед словом как оператор отрицания.

(То есть поиск «Иващенко -лимон» ищет только такие страницы про различных Иващенко, которые составлены без упоминания лимонов.)

>>3202778 →

> вменяемый просмотрщик изображений с поддержкой JXL



XnView MP

>>3205312 →

> Что думаете о моей команде для кодирования в SVT-AV1?



Поясните, почему нельзя было вызвать FFmpeg один раз?

ffmpeg -hide_banner -i "sourcefile.mkv" -sn -map_metadata -1 -map_chapters -1 -b:v 0 -c:v libsvtav1 -crf 19 -svtav1-params keyint=1s:film-grain=8:lookahead=120:hierarchical-levels=5:tune=0 -preset 5 -strict -1 -pix_fmt yuv420p10le -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile (svtav1).mkv"

Сразу скажу ещё, что односекундный интервал между ключевыми кадрами представляется маловатым.

Сразу скажу ещё, что без «-strict -1» можно, кажись, обойтись.

>>08639

> зачем и нахуя люди пилят 10 бит видео?



>>3205319 →

> Что такое 10 бит с математическо-программистической точки зрения?



Раз с с математическо-программистической, то сейчас будут заумныя разсужденія.

(Но не такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется.)

Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «High 10» в рекомендациях ITU-T, это было в марте 2005 года) достаточно быстро (в течение нѣсколькихъ лѣтъ) сдѣлалось ясным, что такие видеофайлы лучше подходят (чѣмъ прежние) не только для таких кадров, пикселы которых с сáмого начала и были тридцатибитными, но также и для 24-битных пикселов (TrueColor), состоящих из трёх восьмибитных (а не десятибитных) цвѣтовыхъ компонентов. (Ну, напримѣръ, понимание этого излагается по адресу https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf в таком PDF, который датирован 2010 годом.)

Вот как это устроено:

① Всякое видеокодирование происходит с внесением потерь в кадры.

② Часть алгоритмов видеокодирования устроена таким образом, что их намѣреніемъ является именно внесение потерь в кадры (съ цѣлью сжатия видеоданных). Другая часть алгоритмов (напримѣръ, преобразование кадров или предсказание одних кадров на основе других кадров), напротив, стремится к точности; потери в таких алгоритмах также вносятся, но в силу погрѣшностей, и алгоритмы устроены таким образом, чтобы свести погрѣшности к минимуму.

③ Понятие «погрѣшность невелика» математически означает «погрѣшность сосредоточена в немногих младших разрядах числа» (скажем, в одном-двух младших разрядах).

④ Построение восьмибитных компонентов цвѣта (для реального экранного пиксела на восьмибитном экране) на основе десятибитных компонентов цвѣта (содержащихся в видеофайле) как раз и сводится к отбрасыванию двух младших разрядов каждого компонента — слѣдовательно, таким отбрасыванием устраняются и всѣ погрешности видеокодирования, сосредоточенные (полностью или хотя бы главным образом) в этих разрядах.

⑤ Первоначальное же построение десятибитных компонентов цвѣта (содержащихся в видеофайле) на основе восьмибитных компонентов цвѣта (содержащихся в исходных кадрах видеозаписи) сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов.

⑥ Благодаря двум вышеупомянутым факторам (большей аккуратности видеосжатия и большой первоначальной избыточности видеоданных) происходит вот что: хотя объём видеофайла растёт при перехода к восьмибитности к десятибитности цвѣтовыхъ компонентов, соотношение качества файла и объёма растёт ещё быстрѣе — слѣдовательно, слегка понизив качество кодирования, можно и в прежний объём видеофайла засунуть видео большего качества.

Вот наглядные примѣры двух вышеупомянутых подвидов алгоритмов — вносящих погрѣшности (устранимые десятибитностью) и вносящих намѣренные потери данных:

⓵ Алгоритм преобразования пикселов из RGB въ цвѣторазностное пространство (и обратно) устроен таким образом, что порождает ошибки округления, которые устраняются, если преобразование происходит в большей разрядности (об этом говорит нам первый абзац по адресу https://en.wikipedia.org/wiki/YCbCr#Y'PbPr_to_Y'CbCr в Википедии).

⓶ Намѣреннымъ же внесением ошибок въ цвѣтность (отбрасыванием ¾ цвѣтовой информации в интересах видеосжатия) занимается при этом другой алгоритм, совершающий цвѣтовую субдискретизацию 4:2:0 (см. https://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0 в Википедии).

Распробовав рост отношения качества видео к объёму файла, многие авторы видеофайлов вот ужé примѣрно лѣтъ пятнадцать стремятся создавать файлы с тридцатибитными пикселами.

>>08560

> встроенный в 11-е окна плеер не может его показать



Поставь Media Player Classic Home Cinema (по адресу https://github.com/clsid2/mpc-hc/releases возьми).

>>09059

> В ffmpeg ставить только по-старому, значением.



Потому что надо ставить не через «-g значение», а через «-svtav1-params keyint=20s».

Тогда к пониманию смысла подключится SVT-AV1 и будет всё ok.

>>09102

> keyint:10s



Не «:», а «=».

>>09133

> ставишь кодек лайт



Чего только не придумают люди, чтобы не пользоваться готовою встроенностью LAVFilters внутри Media Player Classic Home Cinema.

>>09475

> доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom



У меня прекрасные новости для тебя и других подобных любителей хуесосных метафор.

Но эти новости и кого угодно порадуют.

По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 ясно видно, что скорость работы SVT-AV1 под Windows только что ускорили ШЕСТИКРАТНО: в одном из примѣровъ было 0,178 кадра в секунду (на четвёртом пресете), а стало 1,087.

>>09667

> Когда же декодер добавят в FFmpeg?



Когда закончится срок дѣйствія патента.

Ждём до ≈2032 года.
Android: Mobile Safari 208 3211371
>>11361

>Media Player Classic Home Cinema

Android: Mobile Safari 209 3211373
>>11361

>только что ускорили


>сначала сломали скорость, а потом опять вернули


>ускорили

Android: Mobile Safari 210 3211376
>>11373
Алсо этот чмондель указывает шестикратную разницу между пресетом 7 и пресетом 4
screenshot.png4 Кб, 562x208
Windows 7: Firefox based 211 3211385
Тебя в начальной школе научили слову «чмондель», >>11376, но забыли научить читать табличные данные?
Windows 10: Firefox based 212 3211386
>>11385
Нахуя ты себя своим же скрином прикладываешь, долбоебина?
1664699634000.png76 Кб, 259x194
Windows 10: Firefox based 213 3211387
>>11386
А бля, и правда, до

>1,087


я не дочитал
Windows 7: Firefox based 214 3211390
Дочитывать надо.
Windows 10: Firefox based 215 3211392
Никак не отменяет того, что это всего лишь фикс регрессии, чмондель.
Linux: Firefox based 216 3211419
>>11361

> > Когда же декодер добавят в FFmpeg?


> Когда закончится срок дѣйствія патента.


Нахер столько ждать. Лучше забыть и не вспоминать.
Windows 10: Firefox based 217 3211465
>>11361

>под Windows только что ускорили ШЕСТИКРАТНО


Почему числа под люниксам в четыре раза больше. Как ос связана со скоростью кодирования?
Android: Mobile Safari 218 3211533
>>11361

>такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется


>сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов


Действительно, зачем нужны адские заумия для понтующихся имитацией дореволюционной орфографии, особенно, если они не понимают как работает ДКП и прочие интегральные ортогональные преобразования.
Windows 10: Chromium based 219 3211578
>>11385
Что это за картинка, почему на винде так медленно?
Windows 10: Firefox based 220 3211628
Аноны, вопрос может не совсем по теме, но суть такая.
Есть пейлист на ютубе с видео уроками. Самое важное там это аудио, а видео это по сути набор слайдов.
Хочется пейлист себе сохранить, но так чтобы он не занимал много места.

Как быть в такой ситуации? Слишком низкое качество картинки может не подойти т.к. там текст и потом его не поймёшь.
Windows 10: Chromium based 221 3211630
>>11628
GOP 9999
Linux: Firefox based 222 3211634
>>09903
Для подтверждения что он не наебал с ответами, в старом архиве то же самое. Ты конкурсы в интернете никогда не видел? Без подобного пруфа организатор может изменить ответы по своему желанию.
Windows 10: Firefox based 223 3211646
>>11628

>а видео это по сути набор слайдов.


-vf mpdecimate
Если два последовательных кадра дублируются, оно расходует почти 0 битрейта.
Android: Mobile Safari 224 3211703
Как mkv и ass закодить в mp4? Чтоб субтитры не на видео наложились, а чтобы можно было их переключать/выключать.
Android: Firefox based 225 3211706
>>11703
Никак. Потому что mp4 не нужен, это говноформат без поддержки кодеков и с двойной записью на диск ради быстрого запуска (-movflags +faststart).
Linux: Firefox based 226 3211755
>>11703
Можешь рассказать почему такая задача возникла?
Windows 7: Firefox based 227 3211780
>>11703

Таккак вконтейнерахMP4 только https://en.wikipedia.org/wiki/MPEG-4_Part_17 поддерживается вкачестве форматасубтитров, топоневоле придётся искать переводчик изASS вэтотформат.

(Яотаком незнаю, напримѣръ.)
Windows 7: Firefox based 228 3211781
Сраный новодвижок Двача захавал мои Unicode U+00A0.

Пиздец, невозможно общаться нормально.
Windows 10: Chromium based 229 3211790
>>11703
Мне кажется только рядом с файлом с таким же именем положить, а плеер сам подхватит.
Android: Firefox based 230 3211832
Каким поехавшим нужно быть, чтобы муксировать в mp4 а не в mkv?
Android: Mobile Safari 231 3211838
>>11706
Ффмпегопроблемы, остальной софт умеет это делать без двойной записи
Android: Firefox based 232 3211842
>>11838
Может быть, остальной софт имеет все те же функции и кодеки, что ffmpeg, и такой же бесплатный?
Windows 10: Chromium based 233 3211853
>>11228

> В смысле не открывается


image.png

> можешь показать пример?


capture.mkv
Android: Mobile Safari 234 3211854
Сколько времени примерно займет кодирование полуторачасового фильма в фул хд на впсочке с одним некроядром и 512 мб памяти? Стоит ли это вообще того?
Android: Mobile Safari 235 3211855
>>11854
В H265
Windows 10: Chromium based 236 3211856
>>11854
>>11855
Полностью зависит от настроек.
Windows 10: Chromium based 237 3211873
>>11628
Они уже на ютубчики сразу должны быть пережаты как надо, чтобы минимум места занимать. Гугл же не тупые.
Windows 10: Firefox based 238 3212022
>>11873
В принципе да, это тоже может подойти. Скачал длинный видос 30мин+ и не в самом лучшем качестве, но смотрибельный, вышло 31мб.
Android: Mobile Safari 239 3212027
>>11873
Оно пересжато как надо им, максимально некачественно, с минимальным качеством и размером. Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
16568402275590.mp4444 Кб, mp4,
480x480, 0:06
Windows 10: Palemoon 240 3212028
>>11873

> Гугл же не тупые

Windows 10: Chromium based 241 3212224
>>12027

>Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере


И как ты это сделаешь, сверхразум? Как будто этого никто не знает.
Linux: Firefox based 242 3212228
>>12224
Ютуб транскодирует асиками. Транскод асиками даёт возможность транскодировать очень быстро, но не очень качественно.
Windows 10: Palemoon 243 3212229
>>12228
Он имеет ввиду, что исходников от гугла ты не допросишься.
Android: Mobile Safari 244 3212241
>>12228

> но не очень качественно.


А это уже зависит от асика.
Linux: Firefox based 245 3212299
>>12241
Асики от nvidia едва доползли до однопрогодного -preset medium, если говорить о h264. Новейшие асики в видяхах от Intel кодируют AV1 с эффективностью аналогичной x264 -preset veryslow. Для реалтайма может и прорыв, но с кодированием на CPU на медленных настройках не сравниться.
Android: Mobile Safari 246 3212372
>>12299
Ты думаешь там кто-то что-то кодирует на асиках потребительских видеокарт?
Windows 10: Яндекс браузер 247 3212465
Аноны, подскажите, как сделать так, чтобы в конце видео не образовывалось лишних секунд?
Допустим, когда после -r я ставлю 10, то всё нормально
А когда 1 -- остаётся десяток-другой тишины.
Но во втором случае всегда намного меньше веса.
Как собирать шебмы с еденицей фпс и чтобы выходило ровно по времени?

Пример команды:
ffmpeg -r Х -loop 1 -i картинка -i музыка.wav -c:a libopus -b:a 128K -c:v libvpx-vp9 -strict -2 -shortest выход.webm
Windows 10: Firefox based 248 3212474
>>12465
По крайне мере стоит попробовать явно указать -t
Если это поможет и если автоматизировать - я бы скрипт на питоне сделал, который получает длительность и вписывает её. Может быть есть способ как-то через командную строку указать, вроде -shortest - я без понятия.
Ещё есть же кодеки поддерживающие переменный fps, думаю через это можно в конце добавить кадр с длительностью нужной.
Windows 10: Chromium based 249 3212482
>>12465
Это баг даже не -r вроде, а самого ffmpeg когда пытаешься залупить картинку. Хотя мб ты нашел причину, просто ставь -t под длительность музыки.
Windows 10: Яндекс браузер 250 3212490
>>12474
>>12482
Капец затуп, конечно. Совсем про -t забыл.
Спасибо, попробую -- отпишусь.
Windows 10: Chromium based 251 3212505
>>12465
Указывай ещё
-g 9999
-pix_fmt yuv420p
-crf сколько надо
Linux: Firefox based 252 3212522
>>12505

> -g 9999


Зачем? Я с тем же успехом могу тупо один фрейм с картинкой закодировать. Что так что этак прокрутка идёт по пизде.
Windows 10: Firefox based 253 3212563
Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен? Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
Windows 7: Firefox based 254 3212564
>>12563

> Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен?


Он все еще в активной разработке.

> Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.


Используй.
Windows 10: Firefox based 255 3212568
>>12564

>Он все еще в активной разработке.


Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
Android: Mobile Safari 256 3212622
>>12474
>>12482
А как (куда) вписывать -t при склеивании? Выдаёт ошибку, мол, no such a file or directory.
Android: Mobile Safari 257 3212626
>>12622

>tduration(input/output)



> When used as an input option (before-i),


> limit thedurationof data read from the input file.


Вопрос снят, я жопочтец.
Windows 7: Firefox based 258 3212636
>>12568

> Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.


Ядро Linux пилят 20+ лет, перешагнуло 6.0.0, все еще в активной разработке. Дальше что?
Android: Mobile Safari 259 3212637
>>12636
Хомо сапиенс эволюционировал уже как 50 тысяч лет, изобрел спермерочку и всё ещё активно эволюционирует. Дальше что?
Windows 10: Firefox based 260 3212756
А ваш чудо ffmpeg может прям напрямую из видеофайла сразу вырезать нужный кусок без ёбли и кучи команд? Если да, тогда подумаю о переходе, смотрю много контента и много сцен бывает, которые хочется вырезать и отправить подружке
Windows 10: Chromium based 261 3212788
>>12622
В аутпут лучше в параметры кодироваания видео после основных.
Windows 10: Chromium based 262 3212789
>>12756
avidemux резка с ключевого кадра.
Windows 10: Firefox based 263 3212855
Какой максимальный размер шебм на харкаче?
Windows 10: Chromium based 264 3212860
>>12855
В правом нижнем углу формы ввода написано для каждой доски.
Windows 7: Firefox based 265 3212899
>>12505

> -pix_fmt yuv420p



Не нужна субдискретизация при такой частоте кадров.

Это экономия на спичках.
Windows 10: Palemoon 266 3212900
>>12899
Дело скорее в совместимости, охват утюгов, которые декодируют 420 больше.
image.png13 Кб, 617x352
Windows 10: Chromium based 267 3212921
Пачаны, как в ффмпеге задать очередь? у меня есть список команд, но по одной заебался вводить. Спасибо.
Windows 10: Chromium based 268 3212922
>>12921
и ещё ест трабла, первые 1-2 минуты видоса очень пиксельные, потом всё идеально, как фиксить? без поднятия битрейта желательно, конверчу на долгое хранение
image.png447 Кб, 1025x578
Windows 10: Chromium based 269 3212923
>>12922
сука
Windows 10: Firefox based 270 3212932
>>12921
Там одинаковые настройки и только названия разные?
Батник, не? Или скрипт твоей ос, или просто на питоне через subprocess?
Windows 10: Chromium based 271 3212935
>>12932
не там есть траблы с сабами и аудио, надо вручную выбирать дорожки, это заёбно но я составляю такие списки заранее и потом по одной серии конверчу, я хз даже как через батник, типа каждую серию в отдельный тхт и как то потоком поставить?
Linux: Firefox based 272 3212940
>>12922
Не кодировать в CBR. Лучше поставь двухпроходный VBR.
Windows 10: Firefox based 273 3212942
Из 2мб видео эта хуйня выгнала мне 13мб гифку. Ебать. Как ето возможно вообще, я гиф делал наоборот чтобы меньше места занимало.
Linux: Firefox based 274 3212951
>>12942
Ты идиот? Гифки это древний формат с древними принципами сжатия. И вообще гифкам место на свалке истории. Жаль им до сих пор не придумали адекватной замены.

Но сравнивать древний формат из восьмидесятых с современными видеокодеками это конечно шиза.
16495392137830.png698 Кб, 640x640
Windows 10: Palemoon 275 3212952
>>12942

>гиф


>меньше места занимало


Я вижу вы тоже, перекодировщик культурный.
Windows 10: Firefox based 276 3212956
>>12951
Нет, ты идиот. Дальше не читал, иди нахуй.

>>12952
Да. Советы будут?
16459132472280.jpg12 Кб, 292x228
Windows 10: Palemoon 277 3212959
>>12956

>Советы будут


Как сделать из видео набор картинок? Ты неплохо справился.
1622068623711.jpg16 Кб, 230x219
Windows 10: Chromium based 278 3212966
>>12942

> я гиф делал наоборот чтобы меньше места занимало

Обновить тред
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски

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

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