Этого треда уже нет.
Это копия, сохраненная 28 января 2023 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
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

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

Android: Firefox based 279 3213001
>>12921
echo "команда 1" && echo "команда 2"
Windows 10: Chromium based 280 3213013
>>12942
Потому что гиф это ряд картинок jpg буквально. допустим jpg весит 500кб в ней 60 кадров всего. Вот и умножай сколько получится - 30мб
Windows 10: Firefox based 281 3213019
>>13013
До меня правда только что начало доходить, что в исходнике кадры пожаты 264-м, в то время как гиф ничего не жмет сам по себе, только если скажешь ффмпегу жать твою гифку с доп. параметрами.

Обязательно меня идиотом называть, если мне раз в сто лет пришло сделать такую штуку и я сходу не разобрался, что к чему? Почему жизнь ко мне так несправедлива и жестока.
Linux: Firefox based 282 3213022
>>13019
Тебе не нужны гифки для сжатия. Методы компрессии формата GIF устарели, и не могут быть использованы для транскодирования видео в сколько нибудь приемлемом качестве.
Linux: Firefox based 283 3213023
>>13013
Ну у джипега перед гифкой есть преимущество: ДКП. А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Windows 7: Firefox based 284 3213027
>>13023

> А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.


Потому что GIF внезапно loseless (LZW). В отличие от.
изображение.png76 Кб, 816x474
Windows 10: Firefox based 285 3213184
>>12935

>надо вручную выбирать дорожки


Совсем вручную? Ну, если там разумное количество файлов, то просто скопировать строчку нужное число раз и вставлять номера дорожки. Если безумное, то ты всё-равно на ручной просмотр времени много потратишь.
Но даже без скриптов ты можешь просто список файлов сделать с номерами, и через замену заменить разделители на остальные параметры.

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


Какой txt?
Просто кучу команд пишешь и запускаешь, оно их само по очереди все сделает, ещё можешь загуглить что такое shift и %1 в батниках, ещё быстрее сделаешь. Если хочешь вместе, то нужно либо команду для cmd запуска в отдельном потоке искать, либо через питон. И ещё всё зависнет, так как после десяти одновременных экземпляров даже мышка будет плохо двигаться.
Windows 10: Firefox based 286 3213188
>>12942
Пробуй делать APNG. Многие забывают про этот кошерный формат, в то время как слово гифка стало маркером быдла, как и эмэрзе.
Windows 10: Firefox based 287 3213419
>>12942

> Жаль им до сих пор не придумали адекватной замены.


APNG, Animated WebP.
Linux: Firefox based 288 3213426
>>13419

> APNG


Те же методы сжатия что и у GIF. Единственное преимущество перед GIF — поддержка 24-битного цвета.

> WEBP


Не знаю чего там напридумали инженеры из гугла, но WEBM из VP8 будет весить меньше, чем WEBP. Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.

А если пережать в H264/VP9, то полученный файл будет в разы меньше гифки. Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
Windows 10: Firefox based 289 3213492
>>13426

>Единственное преимущество перед GIF — поддержка 24-битного цвета.


А то что та же анимация занимает в 10 раз меньше места, если там схематичное что-то это не преимущество?

>но WEBM из VP8 будет весить меньше, чем WEBP.


Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз.

>Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.


Давай я сделаю отрывок на 2 секунды в 1280х720х60 на 2 мб, а ты покажешь как ты делаешь гифку 1280х720х60 на 2 мб. Таких гифок просто нет, так как там по 50 мб будет, и даже если закодировать в 16 цветов, что выйдет громадными артефактами - это будет всё-равно больше 10 мб весить. А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.

> Но если открыть этот файл в браузере, то там будет видна пауза между повторами.


Вроде бы какой-то флаг кодирования есть в одном из форматов...
16464095199430.gif785 Кб, 250x300
Windows 10: Palemoon 290 3213493
>>13492

> Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз


Запости, хочу глянуть.
Windows 10: Firefox based 291 3213497
>>13493
Анимированный вебп нельзя запостить на сосаче.
Linux: Firefox based 292 3213499
>>13492

> А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.


VP8 да, Анимированный WEBP не факт что вообще влезет в твои лимиты. Опять же, ты даже не пробовал сжимать.
16312011026400.gif774 Кб, 334x298
Windows 10: Palemoon 293 3213500
>>13497
Ненамного юзабльнее получается?
Linux: Firefox based 294 3213502
>>13500
Ты на двач не ориентируйся. Хотя если тебе надо постить на двачах, то всё что не PNG/JPEG/GIF/WEBM/MP4 неюзабельное говно.
>>13492

> Вроде бы какой-то флаг кодирования есть в одном из форматов...


Интересно было бы почитать по этому поводу.
16342059346220.jpg36 Кб, 724x724
Windows 10: Palemoon 295 3213511
>>13502

> Хотя если тебе надо постить на двачах


А что с ними ещё делать? Коллекционировать и рассматривать долгими зимними вечерами? И эти форматы постятся не только на двачах, потому странно хранить изображения в форматах, которые используют 3.5 софтовых калеки.
Windows 10: Chromium based 296 3213514
Разве поддержку webp не сделали с новым движком?
упд. Мда кал нельзя запостить, еще и поддержку mp3 пидорнули.
Linux: Firefox based 297 3213546
>>13514
Зато новый движок не падает постоянно с 502 Плохие Ворота. Хотя нет, подождите...
image.png773 Кб, 1280x720
Windows 10: Firefox based 298 3213552
Вопрос пользователям ff2mpv, это нормально что для запуска данного 30 секундного видео с ютуба в mpv требуется около 5 секунд? Так и должно быть или я что-то не так сделал, чому так долго?

https://www.youtube.com/watch?v=dap5lEuS5uM
Windows 10: Firefox based 299 3213553
>>13552
Нормально. link2mpv так же по времени, хоть там и сишка нативная на клиенте.
Windows 10: Firefox based 300 3213554
>>13552
Ну так пока yt-dlp одуплится, пока mpv всё это прожуёт, секунд 5 и пройдёт. Сам попробуй введи команды в консольку и посмотри сколько по времени весь процесс займёт.
На линуксе кстати быстрее всё происходит.
Windows 10: Chromium based 301 3213619
Зачем нужна WebM, если это кастрированная Matroska? Google явно не по приколу её разработал, в чём тогда смысл?
Windows 10: Firefox based 302 3213651
>>13553
Так это же ютубовское ограничение скорее, а не сишки или ещё чего.

>>13619
Во-первых, немного полегче контейнер, во-вторых предположу что специально.
Написать что бравзер поддерживает webm - норм. А написать браузер поддерживает mkv, но только видеодорожки форматов h264, vp8, ... и аудиодорожки форматов ... - это намного недружелюбнее для пользователей.
Спроси у обывателя какие форматы поддерживает его видео плеер - он скажет что mp4, avi и что там ещё бывает. А при упоминании avc или h264 скажет что первый раз слышит.
Windows 10: Firefox based 303 3213671
>>13553
>>13554
А то что подгрузка при перематывании стрима дольше, чем на ютубе тоже нормально?
Windows 10: Chromium based 304 3213693
>>13651
Что специально? Ну да, я и говорю, что не случайно, только зачем делать матрёшку, которая умеет меньше оригинала?
Картинка в разных вьюверах выглядит по-разному Windows 10: Firefox based 305 3213725
Есть два вьювера - Xnview и Honeyview. В них, что с фильтрами, что без фильтров, картинка отличается - она как-будто поделена на огромные области, которые стыкуются между собой и как бы дорисовывают детали, либо съедают их. Деформируют картинку на пол процента, сохраняя суть, но микро-формы по пикселям отличаются. Почему так? Где картинка правильнее?
Windows 10: Firefox based 306 3213728
>>13725
С масштабом 100% уже выглядят почти одинаково. Но всё-равно отличаются - по краям смещение кадра на пару пикселей, как будто обрезали. И сама область с картинкой на чёрном фоне сдвинута на пару пикселей.
Windows 10: Chromium based 307 3213754
>>13552
Potplayer ytdlp открывает сразу за 1-2 сек, но в общем всё вместе пока ytdlp догрузит тоже 5 сек.
Windows 10: Chromium based 308 3213760
Можно ли в webm для ретардов сделать нормализацию звука?
изображение.png3 Кб, 433x51
Windows 10: Firefox based 309 3213794
>>13760
Вряд ли там галочка есть, но вроде бы там была строчка дополнительных параметров для ffmpeg, вот туда попробуй что-то вроде этого дописать.
https://ffmpeg.org/ffmpeg-filters.html#toc-dynaudnorm
Ещё фильтр loudnorm поищи.
Windows 10: Chromium based 310 3213871
>>13794

> No such filter: 'loudnorm'


не робит
Android: Mobile Safari 311 3213892
>>13871
Пробуй пока не получится, строка ретарда вроде как напрямую скармливается ффмпегу.
Windows 10: Firefox based 312 3213901
>>13871
Хм, может внутренний ffmpeg нужно поменять на более новый.
Там же при сборке можно отключить не нужное, может быть и этот фильтр отключили...

Не знаю что посоветовать, кроме как сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный.

>>13892
Нет, ему же прямо написало, что оно поняло название фильтра, но фильтра такого не обнаружило.
Android: Firefox based 313 3213922
Челы, показывайте ваши команды,
Android: Mobile Safari 314 3213923
>>13922
ffmpeg -hide_banner -i in.mkv
Windows 7: Firefox based 315 3213961
>>13923

> At least one output file must be specified

Windows 10: Chromium based 316 3213978
>>13901

> Хм, может внутренний ffmpeg нужно поменять на более новый.


а как?

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


нихуя не получается, ничего не понимаю...
Windows 7: Firefox based 317 3214053
>>13725

Пиши подробности про XnView.

Он у тебя классический или XnView MP?

>>13426

> APNG



> Те же методы сжатия что и у GIF.



Бредятина!

Во-первых, DEFLATE — это не LZW.

Во-вторых, используются предикторы.

> Единственное преимущество перед GIF — поддержка 24-битного цвета.



Также ерунда: во-первых, не единственное, а во-вторых, PNG поддерживает и 48-битный цвѣтъ.
Windows 10: Firefox based 318 3214055
>>14053

>XnView MP


Да, он.

>Пиши подробности про XnView.


Да я свою претензию уже написал. Ещё могу сказать, что он, имхо, запускается дольше, и если нажать не ту клавишу, то вместо выхода из программы откроешь интерфейс эдакого проводника вместе с картинкой.
Android: Mobile Safari 319 3214140
>>14053

> цвѣтъ.


Зачем ты пишешь неправильно?
Linux: Firefox based 320 3214172
>>14053

> Во-первых, DEFLATE — это не LZW.


Да похуй. Lossless сжатие это последнее что меня интересует.

> Во-вторых, используются предикторы.


Которые предсказывают лишь 1 пиксел от 3-x или 4-x ближайших соседних пикселей, в противовес тому же VP8 где предсказывается макроблок из крайних пикселей соседних макроблоков. И это я ещё не говорю про AV1 где эти блоки могут быть переменного размера и к тому же могут иметь неквадратную форму.
Windows 10: Chromium based 321 3214991
Как быстро скачивать ютуб лайв стримы, которую после того, как он закончится, будет недоступен. ytdl+ffmpeg очень долго качает, потому что качает m3u8 и постоянно парсит hls куски, в общем долго кушает, еще и одним потоком похоже. пробовал 4kdownlaoder, но он как будто вообще не качает.
Windows 10: Chromium based 322 3214995
>>14991
Он еще и качает с конца как бы, вот что хуже всего. Сейчас был стрим на 1 час и 40 мин, скачал 50 мин, и получается первых 50 минут нет.
Windows 10: Firefox based 323 3215043
>>14991
Записать с помощью mpv.
stream-record, или dump-cache команды.
https://mpv.io/manual/master/#options-stream-record
https://mpv.io/manual/master/#command-interface-dump-cache
Windows 10: Firefox based 324 3215519
>>05384 (OP)
Какой из гуев сегодня жив?
Немного полистал поиск на гитхабе, очень много тех кто уже по 2-3 года не обновлялся
Windows 10: Firefox based 325 3215521
>>15519
handbrake
1.mp41,5 Мб, mp4,
850x576, 0:12
Apple Mac: Chromium based 326 3215878
Сделал вещицу вот.
Принимает на вход текстовый файл и картинку, результат видите.

Изначально увидел подобное в тиктоке/телеге, на каналах, где читают с реддита или всякие новости. Но там было так, что текст сразу весь на экране, я решил сделать, чтоб "типа" со скоростью чтения он проявлялся. В итоге год назад сделал, но нигде так и не использовал, сейчас вот вспомнил. Вроде, вполне неплохо, особенно если вместо стандартного синтезатора использовать качественный.
Можно генерить сотни, тысячи таких текстовых видосов батчем.

Вопрос. Где это можно использовать?
Думал сделать канал в телеге или тиктоке, чтоб туда автоматически загружался каждый день видос, допустим, с топ новостью для из какого-то источника.. На этом идеи акончились.
Подкиншь мыслишек, анон?
Windows 7: Firefox based 327 3215898
>>15878
Говно без задач. Буквально. Еще и текст по всему экрану скачет. Пиздец просто.
Apple Mac: Chromium based 328 3215920
>>15898
Не понравилось?
Screenshot 2022-10-17 at 20.37.15.png134 Кб, 1320x702
Apple Mac: Chromium based 329 3216249
Делаю аналог lofi hip-hop радио.
В бесконечном цикле скачиваю следующую песню с ютуба, стримлю ее в буфер, потом из буфера стримлю уже на ютуб.
Чуть-чуть идет, но потом прерывается..
Не могу понять, что за "Broken pipe".. Ничего не смог нагуглить.
Менял по разному размер буфера и битрейт выходного потока, но это без изменений.
Кикие мысли, анончик?

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size= 4kB time=00:00:00.16 bitrate= 195.8kbits/s speed=1.71e+03x
video:0kB audio:3kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 30.555555% Conversion failed! ERROR: [Errno 32] Broken pipe Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='utf-8'> BrokenPipeError: [Errno 32] Broken pipe
Windows 10: Chromium based 330 3216320
>>16249
Пайп в принципе через жопу работает как-то. Пытался последний раз, а он не в какую.
Windows 10: Firefox based 331 3217094
Подскажите пожалуйста
есть видео 1280x720.mp4 сделал гифку 300x300, в гифке черные полосы по бокам как покифксить?
Windows 10: Chromium based 332 3217115
>>17094
Кропом. Скинь команду.
Windows 10: Chromium based 333 3217161
>>05384 (OP)
Установился апдейт на MPHC, после чего пропал звук в вебмках.
Как фиксить?
Windows 10: Chromium based 334 3217197
>>17161
откати апдейт
Windows 10: Firefox based 335 3217752
>>17115
понял, спасибо, учусь по статье https://video.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffmpeg
может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
image297 Кб, 959x530
Windows 10: Firefox based 336 3217841
>>17752

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


Делай кроп хандбраке, там есть удобное превью с возможностью указать кроп on-the-fly. Не еби себе мозги с ффмпежей, он не создан для динамического редактирования видео.
Linux: Firefox based 337 3217844
>>17752
Сделай скриншот кадра с хорошо различимой границей между видео и чёрной полосой.

Открывай в любом графическом редакторе (хоть в фотошопе, хоть в гимпе, не важно, главное в пеинте не открывай). Приближаешь на 400+ %. Берешь инструмент линейка, ставишь горизонтально на границах с контентом и полосой, после чего берёшь горизонтальные направляющие и ставишь направляющие на линейку. У тебя должно получиться 2 горизонтальные направляющие.

Снова берёшь линейку и меряешь пиксели от верхнего угла до верхней направляющей. Это и будет твой «x». Потом меряешь линейкой расстояние от верхней направляющей до нижней направляющей. Это будет твой «h».
Linux: Firefox based 338 3217847
>>17844

> Это и будет твой «y»


Извините, опечатался. Х это всё таки для обрезки по горизонтали, а не по вертикали. Так что это будет не X а Y.
Android: Firefox based 339 3217858
>>17752
ffmpeg -hide_banner -ss X -i in.mkv -frames:v 1 -vf cropdetect -f null -
, где X - время кадра с черными полосами.
Ищешь в выводе строчку где написано crop=..., копируешь это, вставляешь в фильтры, Профит.
Windows 10: Chromium based 340 3217946
>>17752
Я в paint.net на скриншоте смотрю координаты для кропа.
Windows 10: Chromium based 341 3218924
К вопросу, где этот ваш av1 используется: пикабу на него переходит.
Например: https://pikabu.ru/story/passazhirka_kinula_taksista_na_1700r_9580107
Наверно, в него кодируются ролики только из самых популярных постов, как и в случае в ютюбом.
Linux: Firefox based 342 3218961
Мне чел в арматреде сказал что у него ав1-ств кодирует быстрее чем вп9. Ну оно, конечно, возможно, если ав1 поставить пресет 10, но всё же, при равном времени кодирования, у кого будет качество лучше?
Windows 10: Chromium based 343 3219060
>>18924
у меня лично вп9 там открылся, не знаю где ав1.
Windows 10: Chromium based 344 3219094
>>19060
Открой в mpv. Алсо, там даже в названии файла av1. Сохранил – MediaInfo показывает av1. Как ты его в vp9-то умудрился открыть?
Windows 10: Chromium based 345 3219114
Windows 10: Chromium based 346 3219115
>>19094
может у тебя rtx3000
Linux: Firefox based 347 3219141
>>19115

> dav1d


Причём здесь твои rtx?
Windows 10: Chromium based 348 3219148
>>19115
У меня Polaris. Он не то что av1, даже vp9 не декодирует. И да, при чём здесь это?
Windows 10: Chromium based 349 3219157
>>19141
>>19148
а вдруг сайт чекает. в яндекс браузере тоже вп9
Android: Mobile Safari 350 3219452
Какие команды записать чтобы был батник который любой видео файл конвертирует в мп4
Windows 10: Firefox based 351 3219506
>>18961
У меня то же самое даже на пресете 5, на обычном ноутбучном процессоре. А на пресете 7 в разы быстрее libvpx-vp9, при качестве немного выше.
Вообще есть же ещё svt-vp9 какой-то...
Windows 10: Firefox based 352 3219507
>>19452
:st
if %1=="" exit
ffmpeg -i %1 -c:v libx264 -crf 30 -c:a libvorbis -b:a 64k "%~dpn1_h264-27_ab-64.mp4"
::echo "+++"
shift
goto st

Мышкой выделяешь файлы и на батник перетаскиваешь, все строчки кроме длинной чтобы открывать несколько файлов. Но это не сработает, если у тебя несколько аудиодорожек или ещё что-то сложное в видео.
ap969370003938.jpg280 Кб, 3000x1887
Windows 10: Chromium based 353 3219562
>>19507
Большое спасибо.
Кстати твоя команда даже лучше дефолтной, аж в 2 раза файл меньше весит на выходе.
Как научиться писать такие батники?
изображение.png20 Кб, 787x156
Windows 8: Firefox based 354 3219614
Аноны, подскажите.

Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.

Иными словами, видеофайл - с поврежденным последним 0.1%.

Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.

При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.

Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.

Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:

Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.

Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.

Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
изображение.png20 Кб, 787x156
Windows 8: Firefox based 354 3219614
Аноны, подскажите.

Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере MKV, внутри - H.264. Недокачаны потому, что в торренте - mkv с фильмом и "левый" txt-файл, и вот на этот последний кусок торрента нет сидов. Внутри самого торрента эти два файла расположены именно в таком порядке, поэтому у видеофайла не докачаны последние пара мегабайт в конце, а не первые пара мегабайт в начале, где заголовки.

Иными словами, видеофайл - с поврежденным последним 0.1%.

Вот такие видеофайлы почему-то ломают софтверный плеер MPC-HC. Фильм включается нормально, но при любой попытке скипнуть на рандомный момент или даже сменить аудиодорожку во время воспроизведения MPC-HC целиком зависает и начинает с максимальной скоростью ебать жесткий диск, на котором лежит файл.

При этом другим софтом, например, Avidemux (обертка над кодеками для линейного редактирования и перекодирования) файл открывается нормально. Как и с любым другим mkv, фильм открывается медленно (пару минут происходят операции типа Matroska clusters, Matroska images, Checking if timestamps are valid), но после завершения этих операций открытия можно скакать в любое место фильма без проблем и делать с видеорядом что угодно.

Если с помощью mkvtoolnix "пересобрать" этот видеофайл, без перекодирования, оставив все оригинальные дорожки и просто указав промежуток 00:00:00-[за несколько секунд до конца фильма], то фильм пересоберется успешно, без нескольких последних секунд, и вот этот пересобранный видеофайл уже будет нормально воспроизводиться MPC-HC, хотя в нем ровно тот же самый видеопоток, что и в оригинальном файле с поврежденным хвостом.

Mkvtoolnix при такой пересборке пишет в лог следующую ошибку, но пересобирает успешно:

Error in the Matroska file structure at position 12461336755. Resyncing to the next level 1 element.
The last timestamp processed before the error was encountered was 01:54:20.896000000.
Resync failed: no valid Matroska level 1 element found.

Что же касается MPC-HC, то почему-то он зависает и начинает ебать жесткий диск только с теми файлами, у которых не докачаны последние несколько мегабайт в хвосте. А файлы, в которых не докачано что-то в середине, воспроизводятся абсолютно нормально. Само собой, с глюком на поврежденных местах, но по файлу можно спокойно перемещаться, и все остальные фрагменты воспроизводятся без проблем.

Что такого особенного находится в хвосте видеофайла mkv, что MPC-HC моментально детектит какую-то проблему с файлом и сходит с ума?
Windows 10: Firefox based 355 3219659
>>19614
Я заметил такое поведение в utorrent. Когда добавляю новый торрент с многосерийным сериалом, сначала ставлю приоритет файлов по порядку, от 15 (высокий) до 1 (низкий), чтобы серии скачивались по порядку от первой и так далее. Но когда торрент стартует, utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце, только после этого начинается нормальная закачка с приоритетом на первый файл как было задано.

Это специальная фича сделанная для превью, не знаю в каком конкретно софте, но по всей видимости видео так устроено, что для открытия требуется не только начало, но и конец. И это настолько известный факт, что специально запиливают в криентах такую фичу качать в первую очередь начало и конец.
Windows 8: Firefox based 356 3219698
>>19659

>utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце


Такое со всеми файлами, включая последний файл?
Просто начало N-го файла лежит в том же куске торрента, что и конец N-1-го, так что при скачивании начала одного неминуемо скачается и конец предыдущего (кроме редких случаев, когда граница файлов совпала с границами кусков).
Windows 10: Firefox based 357 3219722
>>19698
Да, со всеми. Я специально один раз проследил, в utorrent в списке файлов и есть и диаграмма кусков, так что видно как клиент запрашивает и скачивает граничные все подряд, и пока не закончит этот процесс нормальная загрузка не начинается.

Насчет неминуемой скачки согласен, просто такая формулировка "начало и конец" была когда случайно встретил упоминание этой фичи в интернете, и кажется для другого клиента. Просто так совпало, что заметил такое странное поведение у себя, а потом встретил упоминание как фичу.
Windows 10: Firefox based 358 3219723
>>19722
А, насчет последнего может ты и прав, правда там как раз была озвучка, которую я исключил из загрузок, но вроде последний таки не догрузился, или по крайней мере я припоминаю что висел некоторое время незагруженный.
Windows 10: Chromium based 359 3219735
Как нормализацию сделать в webm for retards?
Windows 10: Chromium based 360 3219813
>>19562

>аж в 2 раза файл меньше весит на выходе.


Ясен хер, там crf 30 стоит, но качество никакого не будет с ним.
Android: Mobile Safari 361 3219883
А в линуксе можно сделать скрипт на который можно было бы перетаскивать файлы или это чисто виндовая фича?
Windows 10: Firefox based 362 3219897
>>19562

>аж в 2 раза файл меньше весит на выходе.


А если 30 заменить на 40 - то будет в четыре раза меньше или типо того, и это ещё от исходного файла зависит.

Прочитать справку по ffmpeg, и справку по bat-файлам, или просто загуглить нужный тебе функционал.
Windows 10: Firefox based 363 3219898
>>19883
У меня точно такой же скрипт на питоне есть, для более сложной обработки файлов, на который можно как на батник скидывать. Я не знаю есть ли такой функционал у файлменеджера люникса - но если есть, то можно конечно, потому что питон там точно работает, а что с местными батниками (там sh-скрипты вроде бы) - я не знаю.
Linux: Firefox based 364 3219916
>>19883
Я на питоне себе напердолил скрипт, который рендерит все видео, которые лежат в одной с ним папке. Не то же самое, но как вариант.
Linux: Firefox based 365 3220022
>>19883
Нет. Там надо открывать консоль, ручками прописывать название скрипта, а уже потом в окно консоли скидывать сам файл, после чего запустить.
Как удалить ёбаные главы и меню навигации при конвертировании видео? Windows 10: Firefox based 366 3220194
Конвертирую видео1 в видео2. Хочу удалить ВСЕ метаданные нахуй. Было: пикрелейтед №1.

https://ffmpeg.org/ffmpeg.html#Advanced-options
-map_metadata -1 стирает метаданные из контейнера и стримов.
-map_chapters -1 должно стирать главы, но на деле получается пикрелейтед №2 в mediainfo глав нет, но осталось обрезанное меню навигации, а в видеоплеере пикрелейтед №3 ебаные главы до сих пор на месте.

КАК ЭТО ГОВНО ВЫРЕЗАТЬ ОДНОЙ КОМАНДОЙ?

Можно через -f ffmetadata сделать дамп метаданных, потом поправить их через блокнот и импортировать обратно, но НАХУЯ, ЕСЛИ МНЕ НАДО ПРОСТО ИХ УДАЛИТЬ?
Можно импортировать пустой файл, но это костыль.
КАК ПРОСТО СТЕРЕТЬ ИХ?
Windows 10: Chromium based 367 3220201
>>20194
удваиваю реквест кста
Windows 10: Firefox based 368 3220250
>>20194
Ок, я разобрался, нужно добавить

-movflags disable_chpl

И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Windows 8: Firefox based 369 3220294
>>11324
С помощью винампа можно, в меню плейлиста.
Windows 10: Firefox based 370 3220376
>>20194
Может быть добавить флаг -dn? По идее там есть только аудио-видео-субтитры, и ещё некие данные, и вот -dn как раз про них. Может быть.
Windows 10: Chromium based 371 3220392
>>20250

> И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.


Объясни.
Windows 10: Chromium based 372 3220462
>>20194
mkvtoolnix
Windows 10: Firefox based 373 3220487
>>20392
Для mp4 контейнера chapters для нормальных людей хранятся в формате quicktime, а для заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись, потому что им нужно выделиться из общей массы.
Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Linux: Firefox based 374 3220502
>>20487

> chapters для нормальных людей хранятся в формате quicktime


> заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись



Что?
Windows 10: Firefox based 375 3220719
>>20487

>Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.


Может. Потому-что

>mp4


Конченый, ни на что не способный контейнер без каких-либо преимуществ, который пропихивают срыночные пердиксы из патентной параши MPEG LA и их подсосы.
Android: Mobile Safari 376 3221108
>>20719
Почему эпл не перейдёт на mkv тогда? Потому что они говноеды?
Linux: Firefox based 377 3221123
>>21108
Потому что это один из членов MPEG LA
Android: Mobile Safari 378 3221171
>>21123
Зачем повторил моё последнее предложение?
Windows 10: Firefox based 379 3221917
Сап, заснял со своего шитого салями пару видосиков, а оказалось, что встроенная камера как то гробит длительность видео, но не аудио, на пикриле видеопоток длиться 59 часов, а аудио 31 секунду, сколько и должно длиться видео.
Понятное дело, любые видеоплееры охуевают от этого, и воспроизводят либо аудио, либо видео.
Ффмпега это тоже касается, он если и кодирует, то сохраняет эту длительность.
Так вот, есть ли какой то способ это исправить? Можно ли заставить ффмпег не тащить длительность видео, а составлять её самому?
Windows 10: Firefox based 380 3221919
>>21917
Пики отклеились.
Android: Mobile Safari 381 3221996
>>21917
Ну есть один способ , но он какой-то дебильный, если кто-то знает получше подскажите
ffmpeg -i video.mp4 -c copy 1.h264
ffmpeg -i video.mp4 -c copy 1.aac

ffmpeg -r 60 -i 1.h264 -i 1.aac -c copy out.mp4
Windows 10: Firefox based 382 3222002
>>21996
Пасиба, добрый анон. Правда пришлось ещё видео повернуть, но это просто.
Windows 10: Chromium based 383 3224175
Все программы для конвертации так адово прессуют процессор, или это у меня майнер-эдишн?
Windows 10: Firefox based 384 3224238
>>24175
Угу там действительно много вычислений требуется.

Есть кодеки, которые прессую карточку, а процессор уже поменьше - но они отличаются плохим качеством по соотношению размера файла к качеству изображения.
Android: Firefox based 385 3224697
ffmpeg.exe -i 123.aif -c:a alac 123.m4a
Нуб в треде. Такая команда будет идентична исходнику или нет? Мне бы в идеале распакуя обратно m4a в aif, чтоб спектр вообще был неизменным. Или все таки после этого уже не будет идентичен?
Android: Mobile Safari 386 3224709
>>24697
В 99% неизменно, нет только если там какие-то специфичные 32 бит и подобное
Android: Mobile Safari 387 3224710
>>24697
Можно проверить такой клмандой:
ffmpeg -i 1.aif -f hash -
ffmpeg -i 1.m4a -f hash -
Если одинаковый хеш то не изменилось
BogdanovBelskyUstnySchet.jpg313 Кб, 1300x1824
Windows 10: Firefox based 388 3225210
Хочу сделать "энкод-бокс", который будет кодировать мою коллекцию старого европейского артхауса, мож ещё аниме и гачимуча порн. Плнирую кодировать через AOM. Какое железо по бомжу и одновременно мощное лучше взяь в такой бокс? Ряженку новую, ряженку старую, мож какие интолы?
Linux: Firefox based 389 3225224
>>25210
Значит так. Можешь брать сразу тредрипер, и 128 ГБ ОЗУ. Запускаешь на этом av1an, и при правильной настройке он будет загружать сразу все эти потоки, ну и молись чтобы оно не полезло в своп.
Windows 10: Firefox based 390 3225255
>>25224
Не, ну можно конечно взяьт с алик 2*EPYC 7601, но нафига мне такая дура? По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.

>av1an


Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Linux: Firefox based 391 3225314
>>25255
Ну у голого aomenc с паралелизмом дела обстоят не очень. Можно конечно врубить tiles, но это ухудшает качество.
Если ты собираешься запускать голый aomenc, то лучше новых топовых интелов не найти.
Но если тебе нужно расскрыть потенциал твоего проца на максимум, тогда тебе придётся осилить av1an. Так то что av1an, что svt оба делят видео на GOP и кодируют их параллельно.
Linux: Firefox based 392 3225316
>>25255

> По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.


Так не бывает. Тут либо файлопомойка, либо сервер нахуй.
TaskmgrBFJ3AMTpTj.png98 Кб, 1081x654
Windows 10: Firefox based 393 3225407
>>25314

>Ну у голого aomenc с паралелизмом дела обстоят не очень.


Действительно... С другой стороны это облегчает выбор, на нужно гнаться за многоядами. Какой-нить 11600k с рук, раскочегареный по одному ядру наверное оптимально зайдёт.
Android: Mobile Safari 394 3225530
>>25210
Дешевле всего купить зион с большим количеством донных ядер. Конечно нормальный современный комп лучше справится
>>25255

> Хз что это такое. По моим тестам AOM лучше работает с грэйном.


Переможный костыль для убогого кодировщика которая делит видео на множество маленьких чтоб нагрузить все ядра
Windows 10: Chromium based 395 3225681
Как нормализацию сделать в webm for retards?
Windows 10: Firefox based 396 3225780
>>25681
В строчке дополнительных параметров указать нужный фильтр (их несколько вроде как) нормализации ffmpeg с нужными параметрами. То есть так же как и в чистом ffmpeg.
Никакого интерфейса для этого может и не быть
Windows 10: Chromium based 397 3225792
>>25780
это не работает
Windows 10: Firefox based 398 3225797
>>25792
Тогда никак. Ограничение интерфейса твоей программы или просто твоей программы, она не может выполнить твою задачу.
Windows 10: Chromium based 399 3225801
>>25797
а как сделать тогда?
Windows 10: Firefox based 400 3225821
>>25801
Через другую программу.
Windows 10: Chromium based 401 3226011
>>25821
Через какую?
Windows 10: Chromium based 402 3226095
>>26011
ffmpeg
1604642780344.webm2,9 Мб, webm,
1280x720, 0:09
sage Windows 10: Chromium based 403 3226158
Windows 10: Chromium based 404 3226327
Как пережать свою коллекцию порнухи, максимально сохранив качество и уменьшив размер файла? Да ещё в идеале используя квик синк, чтобы побыстрей?
Linux: Firefox based 405 3226487
>>26327
Ранее консилиум сжатиешизиков обсуждал данный вопрос. В ходе обсуждений был сделан следующий вывод: лучший способ сжатия видеоархива - купить жёсткий диск.
Android: Mobile Safari 406 3226516
>>26327
Ты попросил невозможного, выбери два пункта:
Максимальное качество
Низкий размер
Быстрота кодирования
Windows 10: Chromium based 407 3226517
>>26327
в 720p crf23-28
Windows 10: Firefox based 408 3226519
>>26327
я не автор вопроса, но интересен вариант: Максимальное качество+низкий размер - подозреваю что надо в сторону H265 копать, но если кто в теме более детальных параметров для заданной цели, рад был бы узнать
Apple Mac: Firefox based 409 3226521
>>26516
Хорошо, убираем быстроту. Сохранить качество, уменьшив размер.
Windows 10: Firefox based 410 3226525
>>26519
>>26521
интересуют также отличия настроек в зависимости от конента, например если у нас не домашнее кино про немцев, а туториалы, о том как домбить бомбас качать кино про немцев баз смс и регистрации, где много текста на экране и мало динамики, бо то качество в котором кино можно смотреть может быть для текста нечитабельно, скорость кодирования думаю проблемой не будет, при наличии NVENC, и МНОГАЯДЕР у процессора...
Android: Mobile Safari 411 3226533
>>26521
>>26525
1. Покупаем ИБП.
2. Снимаем любой разгон, если он есть, обслуживаем пеку полностью.
3. Собираем ffmpeg с поддержкой VVC и модулей.
4. Ставим модуль кодирования xHE-AAC.
5. Выбираем самые жирные настройки для кодирования.
6. Начинаем кодировать.
7. Умираем от старости.
Windows 7: Firefox based 412 3226534
>>26533
Чтобы умереть от старости даже собирать ничего не надо - av1 через libaom на veryslow сгодится.
Windows 10: Firefox based 413 3226544
>>26534
а профиты то от av1 veryslow будут? так то дурной задачей можно всегда себя нагрузить, вопрос то в профитности затеи, насколько например будет прирост компрессии в сравнении с кодекнейм, ну и без более детального указания параметров тоже вопросы возникают - или мы Лузлесс кодируем или определенное ограничение качества ставим...
>>26533
а здесь немного я не понял прекола, зачем нам xhe-acc с аудио по моему вообще проблем особыхх нету как по мне, и маста аудио дорога занимает на порядок меньше... вопрос еще к воспроизводимости контента возникает, а то можно такого накодировать что ничем не откроется... и какой тогда смысл этого всего...
Android: Mobile Safari 414 3226583
>>26534

>av1


А как же какчество-то? Нам же важно сохранить какчество при минимальном размере.
Windows 10: Firefox based 415 3226588
>>26534
Потестил AV1 - для него норм кодировщик надо, потому что одни умеют 24 потока заюзать, а другие непонятно чем занимаются во время кодирования и оно капец долгое выходит... но уменьшение размера впечатляет, хотя разница в качестве на глаз заметна даже...
>>26583
тогда остается только HEVC Loseless для качества, ну или с высоким качеством на крайняк... av1 хорош на случай когда и места жалко, но и файл пусть полежит...
Windows 7: Firefox based 416 3226590
>>26588
Там два енкодера av1 если что. libaom-av1 референсный, был в основном добавлен для тестов. Овердохуя медленный, но жмет как надо. И libsvtav1 - над ним еще активно работают, но в последних версиях ffmpeg (5.1+) он уже довольно прилично работает и шустро.

> хотя разница в качестве на глаз заметна даже...


crf поменьше?
Windows 10: Firefox based 417 3226592
>>26590
та вроде в 0 до упора (я вообще HANDBRAKE юзал для конвертации, не хочу с терминалом возится на винде), но с 30 мб до 1 сжать это конечно сильное заявление на успех...
Windows 10: Firefox based 418 3226595
>>26590
по качеству хотя может то HEVC чего намутил, с которым сравнивал, бо HEVC как будто подтянул четкость или контраст, но это не точно...
по факту все экспериментально походу решать надо... так как не все настройки всем подходят...
Windows 10: Firefox based 419 3226703
>>26667 (Del)
Побеждает, конечно. Только попробуй найди этот Tencent V265 или Pheonix265, QAV1, чтобы можно было сжимать в него.
Windows 10: Firefox based 420 3226776
>>26667 (Del)
Что-то не вкурю почему или 4:1:1 на скрине или 6:1:1 куда ж с такой субдискретизацией сунуться - эт дичь какая-то выходит... И так ли велика разница проприетарщины и опенсорса
Android: Mobile Safari 421 3227259
>>26659 (Del)
В импортных железках? В любом случае, если это н
хардварные имплементации, то они сосут бибарандум у софтовых реализаций.
Windows 10: Chromium based 422 3227294
>>26667 (Del)
Мне даже интересно, где они эти hw266 достали и на какой процессере или плеере воспроизводили вообще какой производительностью
Windows 10: Chromium based 423 3227514
Анончики, приветствую!
В общем, есть около 15000 файлов в mp3 и звук который нужно наложить поверх этих файлов, типа вотермарки которая будет звучать поверх музыки. Как это реализовать массово? Чтобы не вбивать по файлику, а вхуячить папку входа и папку выхода с теми же названиями файлов по итогу?

Если есть более простое решение - буду премного благодарен, поскольку несколько дней гугления ни к чему не привело. Либо я находил программы без описания работы, либо решения которые делают только по одному файлу за раз.
Windows 10: Chromium based 424 3227531
>>27514
ffmpeg batch av converter, там все есть, и кодирование в твоих настройках, и генерация древа папок из сорса, плюс одновременное кодирование в отличии от обычного ффпмег, либо батник пердоль. Для себя лучше не нашел.
Windows 10: Chromium based 425 3227533
>>27531

>одновременное кодирование


Параллельное кодирование точнее. Не дописал, что сам кодировал 36к ogg файлов в opus. Довольно быстро сделал в 24 потока.
Windows 10: Firefox based 426 3227611
Надо захватить звук с ютуба. Именно какой он на ютубе, а не мп3 который предлагают разные сервисы по скачиванию с ютуба.
Что мне потребуется? Я так понимаю, это вполне возможно, если знать что вбить в командную строку.
Windows 7: Firefox based 427 3227615
Linux: Firefox based 428 3227616
>>27611
На телефоне NewPipe без командной строки, на компьютере - да, yt-dlp -F и yt-dlp -x --audio-format=
Windows 10: Chromium based 429 3227707
>>15043
Однажды сработало, а щас не работает. Стрим рекорд не дает скачать стрим с ограничением по возрасту, а дамп кэш вообще пишет: опция не найдена.
Linux: Firefox based 430 3228633
Сап ананасы! Давно забыл комманду для объединения двух видосов в одно так чтоб одновременно проигрывались да, я про увеличение резрешения видево и нагуглить не получается. Вообще мне сейчас понадобилось не видео объединить а две гифки одинаковых размеров. Выручай анонч с меня как обычно
Windows 10: Chromium based 431 3230011
Спалите быдлу — в каком формате писать/конвертировать видео малого размера, чтобы не сыпалось квадратами.
Мой фаворит это порнуха высотой кадра 180. Высокая продолжительность видеоряда, но всё различимо и без квадратов. Хочу так же.
Windows 7: Firefox based 432 3230025
Windows 7: Firefox based 433 3230030
>>30025
Во-первых есть AV1 который всем его лучше, а во-вторых оба не подходят для указанной задачи, потому что очень любят мылить картинку.
1582269870469.jpg12 Кб, 225x225
Windows 10: Chromium based 434 3230033
>>30011

> высотой кадра 180


> всё различимо и без квадратов

Linux: Firefox based 435 3230197
>>30033
Ну да, так и делают. 320x180 ставят на 25 минут чтобы картинка не сыпалась на квадраты на таких битрейтах. Если просто взять и при том же битрейте поставить 360p, то чёткость от этого не увеличиться, а артефакты полезут со всех щелей.
Android: Mobile Safari 436 3230738
>>30197
Наркоман? Любая картинка при более высоком разрешении выглядит лучше
7-zip Windows 10: Firefox based 437 3230819
>>05384 (OP)
Сжал только что сохранения для игры Rimworld - 6495 Мб превратились в 56 Мб. Я конечно любитель сжимать сжимаемое, но это уже чересчур.
Linux: Firefox based 438 3230910
>>30738
Чтобы картинка выглядела лучше — нужно потратить больше битрейта. Битрейт определяет количество информации, которое будет закодировано. И поставь ты хоть 1080p, но на 128kbps картинка будет выглядеть мыльным говнищем.
1669555896095.png26 Кб, 477x265
Windows 10: Firefox based 439 3230933
>>30819
Пикрил для тебя.
можно еще через консоль в lzx сжимать
Android: Mobile Safari 440 3231039
>>30910
При этом в 1080 она будет выглядеть лучше чем в 240. Потому что у кодировщика есть больше данных, больше разрешение чтоб разгуляться. Могу даже показать пример
Windows 10: Firefox based 441 3231046
>>31039
Ну давай, показывай пример.
Linux: Firefox based 442 3231739
>>30819
Ожидаемо, там же все сохранения - однотипные XML файлы, к тому же не инкрементальные
Windows 10: Chromium based 443 3231779
Как записывать стримы с ютаба?
143532280400032.jpg88 Кб, 1280x720
загадка от Жака Windows 10: Chromium based 444 3232057
Почему телек некоторые файлы проигрывает без нареканий, а некоторые ругает ("тип файла не поддерживается"). Контейнеры ведь одинаковы, формат одинаков. Различаются файлы на каком-то наноуровне, которые не виден в свойствах?
Windows 7: Firefox based 445 3232061
>>32057
Очевидно что формат не одинаков. У многих кодеков есть вагон и маленькая тележка профилей, добавляют их со временем, поэтому в старых железках/софтинах может не быть поддержки. Как в свое время было с 10 бит в h264.
Linux: Firefox based 446 3232388
>>31779
Попробуй youtube dlp. Но я не пробовал.
Windows 10: Chromium based 447 3232959
>>31779
в этом или прошлом треде было. Через mpv
Windows 10: Chromium based 448 3232960
Linux: Firefox based 449 3232974
Как сжать видео не просрав качество?
Снял минуту обс в мкв, 115 мб - конвернтул ффмпг в мп4 - 50мб, двощ все равно не грузит. Что делать?бочку
Linux: Firefox based 450 3232993
>>32974
Длительность?
Linux: Firefox based 451 3233008
>>32993
Немного больше минуты 115 мб в мкв.
Windows 7: Firefox based 452 3233014
>>32974

> мкв


> мп4


> Что делать?


Идти читать что такое контейнеры и кодеки, чем они отличаются, как задавать качество/битрейт в ffmpeg для них, а так же - какие форматы поддерживает двощ.

> (Linux: Firefox based)


Дожили - неграмотные линуксойды домохозяйки.
Android: Mobile Safari 453 3233025
>>33014
Задаю конкретный вопрос в целевом треде.
Я всю жизнь занимался совсем другой темой, вот и спросил, а нонейм мне говна вылил, хотя явно мог бы правильные ключи для ффмпг сказать. Пшел нахуй.
Linux: Firefox based 454 3233037
>>33025

> Я всю жизнь занимался совсем другой темой


Пруф несёшь, что не бесполезный кусок говна и не трепло. Тогда подумаем, сказать тебе ключи или нет.
Windows 7: Firefox based 455 3233043
>>33025
Если ты даже в элементарных вещах в кодировании ничего не понимаешь, значит, несмотря на то что результата ты хочешь и какого получше,вообще не утрудил себя почитать ничего по теме. Сразу побежал требовать чтоб за тебя все сделали зашибись, а ты сидел шиковал на всем готовом. Никакого желания объяснять азы тому кто не желает учиться нет. Качай какой-нибудь WebM for Retards, тебе хватит.
Windows 10: New Opera 456 3233187
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A
frame= 0 fps=0.0 q=0.0 size= 0kB time=-577014:32:22.77 bitrate= -0.0kbits/s speed=N/A

Что с этим говном делать? Почему при первом проходе и начале второго не показывает ни номер фрейма, ни время?
Windows 10: Chromium based 457 3233312
>>33187
потому что анал изирует а не кодирует.
Windows 10: New Opera 458 3233363
>>33312
Раньше было, а после какой-то обновы перестало показывать. А мне нужно процесс контролировать, проценты выводить. Где мои проценты?
Ubuntu: Firefox based 459 3233412
Linux: Firefox based 460 3233469
>>33008
Что значит немного больше? Мне битрейт рассчитать надо.
Например, на одну минуту у тебя уйдёт 2.8 мегабит.
Linux: Firefox based 461 3233476
>>33412

REPLACE THE AUDIO
@
NO PROBLEM
@
FIX THE IMAGE
@
NO PROBLEM
@
CONVERT THE VIDEO
@
NO PROBLEM
@
CONCAT A PNG SEQUENCE
@
NO PROBLEM
@
CREATE A NON-PLAYABLE FILE
@
NO PROBLEM
Linux: Firefox based 462 3233477
>>33412
Premiere Pro has the worst encoders ON THIS PLANET
Windows 10: Chromium based 463 3233540
>>33363
Сколько пользовался четвертой версией, всегда так было
1631056703870.webm19 Мб, webm,
240x300, 0:07
Windows 10: Chromium based 464 3234486
Linux: Firefox based 465 3234493
>>34486
Я уже 2 минуты смотрю 7-ми секундное видео.
Windows 10: Firefox based 466 3234495
>>34493
Дурачок, ускорь его в 2 раза, чтобы быстрее увидеть хлопок.
Linux: Firefox based 467 3234499
>>34495
Ты думаешь я не понял прикола? Давай, рассказывай, как ты зациклил кусок видео?
Windows 10: Firefox based 468 3234515
>>34499

>как ты зациклил кусок видео?


В видеоредакторе. Это 20мб видео разрешением 200х300
Linux: Firefox based 469 3234576
>>34515

> В видеоредакторе.


Да ну. Ты ещё расскажи что Premier Pro умеет рендерить в WEBM. И не просто рендерит, но и поддерживает уникальные особенности этого формата, вроде смены разрешения видеокадра на лету.
Windows 10: Firefox based 470 3234589
>>34576
Значит не Premier Pro
Linux: Firefox based 471 3234651
>>34576
К премьеру можно подрубить воукодер или даже ффмпег (через костыли). Полгода давился давинчи, заебало врать себе что он не дерьмо собачье. Вернулся на премьер.
Windows 10: Chromium based 472 3235854
как записывать стрим с ютаба?
изображение.png11 Кб, 1015x87
Windows 10: Firefox based 473 3235856
>>35854
Найти детектор потока, расширение для браузера, скорми ссылку в ffmpeg как у меня примерно и запусти. -t и -ss по крайне мере на твитче поддерживаются.

Предположу что youtube-dl справится тоже, скорми ссылку с флагом -F, посмотри даёт ли он форматы. Ещё youtube-dl умеет выдавать ссылку без запуска браузера. Но если загружать прямо через youtube-dl он не умеет обрезать часть стрима до загрузки.
Windows 10: New Opera 474 3235881
>>35856

>youtube-dl


его уже лет пять как закрыли
>>35854
yt-dlp как обычное видево
изображение.png15 Кб, 409x251
Windows 10: Firefox based 475 3235883
>>35881
Да? Я первый раз про твою штуку вижу.
А моя вроде как работает и всё загружает без проблем.
Linux: Firefox based 476 3235907
>>35856
Что такое BSF?
Windows 10: Chromium based 477 3235953
>>35881

> yt-dlp как обычное видево


а если видео 18+ и требует аутентификации?
Windows 10: Chromium based 478 3236015
>>35953
Тогда добавь параметр кукисов.
Windows 10: Chromium based 479 3236121
>>36015
не получается
Windows 10: Firefox based 480 3236130
>>35907
Что-то от bit stream format, наверное.
Linux: Firefox based 481 3236531
Windows 10: Firefox based 482 3236634
>>35953
yt-dlp.exe --username ИМЯ --password ПАРОЛЬ ...
Windows 10: Firefox based 483 3236675
Windows 10: Chromium based 484 3236727
Доброе. Надо объединить видео и аудио без нюансов и без потерь качества, без сжатия. FFmpeg справляется с данной задачей? Еще год назад объединил для сравнения в премьере и в ffmpeg, звук отличался точно.
Android: Mobile Safari 485 3236731
>>36727

>FFmpeg справляется с данной задачей?


Конечно.
ffmpeg -i video.xyz -i sound.uvw -c copy output.mkv
16149126362079.mp468 Кб, mp4,
404x454, 0:03
Windows 10: Firefox based 486 3238232
Скиньте плиз строку для кодирования аудио + статичная картинка, в webm. Желательно чтобы ширину картинки указать и время вырезания. В гугле куча разных, но не нашёл идеальную.
Windows 10: Firefox based 487 3238499
Дошли руки до перекодирования запасов порнухи в HEVC. Занятно, что примерно 90% видосов в fullHD и выше сжались на 10-40%. А вот старые всякие с 480p порой даже распухли по сравнению с олдовыми версиями на ископаемых кодеках.
Windows 10: Chromium based 488 3238507
>>38232
ffmpeg -loop 1 -r 1 -i "cover.jpg" -i "music.flac" -t 00:04:05.23 -c:v libvpx-vp9 -pix_fmt yuv420p -colorspace bt709 -vf scale="720:720" -c:a libopus -b:a 128k -map_metadata 1 -shortest "OUTPUT.webm"

если гиф, то у меня двухпроходное
Windows 10: Chromium based 489 3238508
>>38499
Смысла нет, давно уже все перекодировали за тебя.
Windows 10: Firefox based 490 3238511
>>38508
ан нихуя. порой даже в одной раздаче в куче древние 263 или вообще окаменевший кал жопса типа mov и более-менее современные 264 или даже av1
поскольку я нищук со старой 2070 - то мне и нахуй не нужон ваш av1, зато HEVC вполне даже охуителен.>>38508
16675856364570.jpg487 Кб, 1771x1254
Windows 10: Palemoon 491 3238517
>>38511
Зачем? Множить скорбных шакалов в мире?
Windows 10: Firefox based 492 3238521
>>38517
только чтобы тупо сэкономить место на hdd. сейчас такие exos на 6 тб каких-то запредельных денег стоят. так что перекодировка экономнее, чем второй покупать
16679249879837.png167 Кб, 375x479
Windows 10: Palemoon 493 3238524
>>38521
Может просто меньше дрочить? Я картинки то сохранённые второй раз редко открываю, а тут аж порнуху терабайтами пересматривать
1527012467-496da479b16157f9774d1e5401ba59b0.jpeg106 Кб, 1080x1080
Windows 10: Firefox based 494 3238527
sage Windows 10: Firefox based 495 3239218
>>13552
Для ускорения этого нужно выбирать best, а не dash, но это 720p всего. А еще вот такую строку:
https://paste.debian.net/plainh/951b739a
Ты же запсукаешь сразу два потока отдельные экстракты видео и аудио, более того - dash на ютубе железно ограниченные скоростью, из-за этого тоже долго, да и то что dl/dlp скомпилированный упакованный exe с тысячами скриптов, пока он расчехлится тоже уходит время.
Windows 10: Firefox based 496 3239335
А что кодировать то кроме порно и аниме?
16640866191290.jpg445 Кб, 828x1025
Windows 10: Palemoon 497 3239358
>>39335
Зачем вообще кодировать?
Windows 10: Firefox based 498 3239426
>>39335
Видосы с мобилки.
Мобилка без процессора, потому там часто константный битрейт громадный и сжатие очень условное, чтобы оно успевало в реальном времени кодировать - после перекодирования часто можно без заметных потерь раз в 5-10 пожать.
Windows 10: Chromium based 499 3239506
>>39335
Шебмы для харкача.
1623157950503.png400 Кб, 2000x2000
Windows 10: Chromium based 500 3239510
ПЕРЕКАТ

https://2ch.hk/s/res/3239508.html (М)

ПЕРЕКАТ
image.png65 Кб, 220x220
Windows 10: Firefox based 501 3247394
k.mp4300 Кб, webm,
1280x720, 0:09
Windows 10: Chromium based 502 3249474
Windows 10: Chromium based 503 3249566
>>49474
И чё?
Windows 10: Chromium based 504 3260758
>>39335
порно личное снятое на профессиональную камеру надеюсь? или ты блюреи японские рипаешь?
Windows 10: Chromium based 505 3260763
>>38499
после того как ты провел тесты на разных битрейтах и выбрал приемлемый для тебя уровень качества?
кстати скиньте софт для таких тестов. я только знаю что сравнивать видосы можно в kinovea (привет из 2004) и ICAT (не поддерживает даже h265 лул)
вот бы новые видеокодеки с беспотерьной совместимостью со старыми как jpeg xl... я недавно нагулил в егоном треде что был такой для пережатия h264 в тот же формат но не особо много экономил.
Тред утонул или удален.
Это копия, сохраненная 28 января 2023 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски