Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
В прошлый раз мы весь тред обсуждали тонкости сжатия и разбирали команды.
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 (М)
Шапку читать.
>Не работает ссылка.
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
>То это это про битность кодирования отдельных гармоник после косинусного преобразования?
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был 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 бит. В большинстве случаев это анимешничьи выебоны.
>Не работает ссылка.
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.
>То это это про битность кодирования отдельных гармоник после косинусного преобразования?
Не гармоник, а коэффициентов преобразования.
Давным давно в далёкой-далёкой галактике был 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 бит. В большинстве случаев это анимешничьи выебоны.
>- вычисления выполняются с большей точностью
Не очень понятно почему все промежуточные вычисления не делаются в 32 бита, и только конечное представление ужимается в 8-10 или другое случайное количество бит, где может быть как целое число, так и даже своя шкала, по типу что 0b0001 == 0.001, 0b0010 == 0.003, 0b0011 == 0.007 (которая супер-медленная для промежуточных рассчётов, но чуть эффективнее для сохранения) - как будет короче записать, с обычными числами или сохранив ещё и таблицу для нужного количества бит.
Просто по идее разница между 0 и 1, или 3 и 4 на глаз заметнее, чем разница между 245 и 246, если даже тупо в пеинте одну компоненту поменять, так как яркость заметнее изменяется - потому я и предложил шкалу имеющие шаги ниже ближе к нулю.
>И не обязательно с плавающей точкой.
Да я просто как вариант. Процессор вроде бы одинаково быстро умножает.
>не должно такого преобразования
Точно? То есть оно видя исходные сигналы уже в нужном представлении пережимать их сначала в rgb не будет?
Но такое не сработает, если есть хоть один фильтр что-то делающий с rgb-представлением, и тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера.
Понял в двух словах вроде бы, спасибо.
> Процессор вроде бы одинаково быстро умножает.
Даже самые современные x86_64 работают с целыми разика в полтора быстрее. Плюс умножение и сложений целых и дробных с фиксированным разделителем происходит без потерь, а у дробных с плавающим разделителем с этим ай-ай-ай.
> Не очень понятно почему все промежуточные вычисления не делаются в 32 бита
Потому, что прифит околонулевой, а затраты растут сразу и существенно. В качестве примера предложу тебе в столбик 31 на 42 и 7531 на 8642. Просто держи в уме, что кодер и декодер у нас могут стоять хоть в утюге и быть чисто аппаратными, и требования по минимуму потребляемой энергии отменять никто не будет. А кодер и декодер должны иметь существенную универсальную часть, и для оценки качества должны иметь точно воспроизводимый результат. За последнее при принятии, например, стандарта уже на MPEG-4 ASP H.263 бились (в H.264 уже победили, точно определив универсальный единый для всех реализаций способ вычисления ДКП).
> потому я и предложил шкалу имеющие шаги ниже ближе к нулю
Не могу понять, какая тут связь.
>в нужном представлении пережимать их сначала в rgb не будет?
Если явно не попросишь, то не будет. Соответствующие проверки в коде libswscale есть.
>тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера
Здесь тоже вопрос не понимаю.
> Здесь тоже вопрос не понимаю
Это скорее не вопрос, а мысли в слух, никто не может взять в толк почему libjxl входящий в состав ffmpeg не может пережимать jpeg без потерь, как это делает другая реализация энкодера этого формата, а занимается преобразованиями, которые приводят к искажениям. В то время как для libx264, входящий в тот же ffmpeg позволительно сразу работать с yuv
В общем не бери в голову.
>Даже самые современные x86_64 работают с целыми разика в полтора быстрее
Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Причём там же инструкция есть для сложения-умножения для плавающих на 32 и 64, а для целых я такой не вижу.
>Здесь тоже вопрос не понимаю.
Почему libjxl поддерживает перекодирование из jpg без потерь только вне ffmpeg?
>Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Знаешь, ты меня заинтриговал. Я погуглил. Оказалось, что моë мнение ошибочно.
https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
Посоны утверждают, что в зависимости от длины чисел и конкретного камня получается по-разному. Если тебе есть, что сказать, то я бы с удовольствием послушал подробности. По остальным тезисам замечания есть?
Я может слепой, но там начиная с хасвеллов инты считаются быстрее, что короткие, что длинные, если это инты, конечно.
Сжатие медиа - это, конечно, хорошо. Но как на счёт сжатия документов и программ?
Отдаю предпочтение 7-zip с кодеком lzma2 на максимальных настройках. Кто-то скажет, что мейнстрим, но выбирать не из чего. Альтернативы - мутная незадокументированная чепуха, без комьюнити и без бинарников. Которая, к тому же, не может сжимать несколько файлов и папки - то есть сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь в модный архивный кодек. А иногда и выигрыша в степени сжатия нет.
Я просто тестил, и операции умножения-сложения на моём ноуте (да и не только на нём, до чего дотянулся) быстрее для float32, чем для целых чисел. Даже без simd.
Медленнее, только если упирается в скорость памяти, и условно говоря целые числа влезают в кеш, а флоаты - нет.
Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.
>>05719
Деление вообще хуета неоптимизированная, но оно и не используется в кучи вычислительных задач. Как впрочем и тригонометрия, где тебе перемножать коэффициенты в разы быстрее, чем складывать углы и считать синус-косинус заново, и в кучи задач тригонометрию можно на что-то заменить.
>>05730
Можешь диск в оперативке сделать, и тар на нём размешать.
>Но как на счёт сжатия документов и программ?
Всё плохо, сжимать с потерями нельзя, потому хотя бы немного неупорядочненную информацию сжать нельзя. Программы не сжимаются, документы, только если формат текстовый, в противном случае едва ли даже 20% получишь. А если там хоть одна картинка в документе, то смысл теряется.
Кстати, в ffmpeg можно монтировать видосы как в Адоб премьере, или такая себе затея?
Ну, она сложная, если ты, как пердолики сверху, будешь ебаться с битностью, хуитностью и прочими параметрами, которые нам, простым домозяйкам, непонятны. А на базовом уровне это обычная консольная утилита - скормил аргументы в нужном порядке и получил профит. Изи ту лёрн, хард ту мастер.
> сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь
И упаковываешь их в tar. И теребишь им bzip2.
А что, перенаправление ввода-вывода отменили уже?
>>05718
Насколько я понимаю результаты, суть в том, что целые и дробные числа числодробят у Штеуда разные процессоры, разрабатываемые разными командами. И коммерческие камни компонуются из наиболее отработанного на момент выхода решения, плюс ограничения ввода-вывода, которые даёт память и её контроллер.
>>05731
>Не знаю, могу примерно описать что имею ввиду про неравномерную шкалу и у меня есть ещё несколько теоретических вопросов, но ничего такого важного.
Есть монография «Recent Advances in Multimedia Signal Processing and Communications» Растислава Лукача. Номерок в libgen — 651313.
Там есть первая же заметка «Color in Multimedia» о цвете как ощущении, цветовых моделях и пространствах.
>и тригонометрия
Таблицей берут или в ряд Тейлора же.
>>05743
> ffmpeg это какая-то сложная фигня
Так-то, да. Я её исходники читаю с большим трудом. И не потому, что они написаны плохо. Примерно соглашусь с >>05793.
>>05793
>можно монтировать видосы как в Адоб премьере
Можно, но зачем, когда она для этого, мягко говоря, не приспособлена.
> или такая себе затея?
Очень-очень такая себе. Если есть желание автоматизировать, то есть vapoursynth — нелинейный видеоредактор питоном (в смысле, что он построен как фреймсервер с питоновыми биндами и опускаемой обвязкой — можно сразу на упрощённом питоне писать редактирующий видео сценарий).
Ты ошибся тредом.
>целые и дробные числа числодробят у Штеуда разные
Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.
Выбирай JPEG XL если тебе нужно равномерно размазать битрейт по всей картинке.
Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
И?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
>Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.
Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
Так это и есть H264, но неправильный, 10-битный. Почему он сам не додумался скачать нормальный рип или ремукс, ума не приложу.
>не додумался
Потому что я еблан и я это признаю. На своем же скриншоте >>08229 не разглядел h264, охуеть я баран. Но от моего самобичевания лучше не станет, поэтому к теме.
Все дело в том, что я положил кучу сил на сборку конкретно этого релиза, но по какой-то странной причине не обратил внимания на битность видео, ебать релизеров в сраку. Я своими руками собирал дорожки с озвучкой и клеил их, а в итоге обнаружил, что встроенный в 11-е окна плеер не может его показать и я не сразу понял, что к чему. Да, забыл сказать для чего это все. Я никуда не выкладываю, просто хотел в коллекцию, то есть длясибя.
Короче что проще - скачать нормальный рип и заново приклеить озвучки или все же можно перекодировать видео в уже готовом контейнере?
>>08517
Храни тебя бог анон, но я вот уже сам начал сомневаться, что пережимать рип норм затея.
Смотри, у тебя есть 2 пути, и оба ведут к торрент-трекеру.
Если для тебя установка сторонних софтовых плееров по какой-то причине неприемлима — качай рип.
Если ты хочешь сам пережать видео и ты знаешь как ты это будешь делать — качай ремукс или BluRay/DVD.
Если имеешь дело с WEB, пережатие скорее всего не требуеться, убедись только что у тебя формат видеодорожки H264 8bit а не H265 10bit HDR DolbyVision.
То есть вариант с еблей мы даже не рассматриваем, окей. Ладно, я все понял. Есть еще вопрос: зачем и нахуя люди пилят 10 бит видео? Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой. У меня пиздатый моник, не хдр конечно и не 10 бит, но у большинства людей с торрентов тоже не одиссей джи 9 или че там щас в тренде. И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
> То есть вариант с еблей мы даже не рассматриваем
Второй вариант это и есть вариант с еблей, где ты берёшь исходник лучшего какчества и уродуешь. Не рассматривается вариант пожатия пожатого.
Цвета лучше, сжатие лучше. Дебандинг.
> скочал нормальный 10-ти битный рип
> гавна встроенная в гавну не поддерживает нормальный 10-ти битный рип
> надо угандошивать нормальный 10-ти битный рип пережатием в менее сжимаемый 8-ми битный чтобы гавна встроенная в гавну поддерживала
> Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой.
Разница есть. С 8-бит в темных сценах аниме ебаные круги бандинга.
И в hi10p не тратится битрейт на борьбу с этим бандингом или чем-то другим, так что энкодер может либо сделать поменьше вес видео, либо улучшить качество с тем же весом.
> И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
Зачем - ответ выше, бандинг и сжатие. А почему - потому что могут.
Те аниме видео обычно смотрят с субтитрами. И не .srt, а .ass с оформлением. Так что требования к плеерам уже повышены. И т.к. смотрели на пк/ноутах, а не железных плеерах, то наличие аппаратного декодирования не было критичным, процы могли справиться софтверно с hd/fhd и 2-3к битрейтом. Энкодеры решили зафорсить 10бит с 2011, и это прошло относительно безболезненно, зрители обновили плееры и продолжили смотреть.
Видели шутки, которые не шутки, про то что порно индустрия много раз первой осваивала и распространяла новую технологию? Вот с аниме по сути похожая ситуация тогда произошла.
Как сейчас не знаю. Кто-то энкодит пиратство в h.265 или AV1?
> Кто-то энкодит пиратство в h.265 или AV1
Анимешники и энкодят, даже тестировали fate'вым касанием небес процессорный декод av1 в райзентреде.
>и уродуешь
Ну зачем ты так..
>>08652
Доводы разумные и звучит все круто. Не круто, когда ты мультики не смотришь (за редким исключением) и при случае попадаешь вот в такие ситуации. Ну бывает. Большое тебе спасибо.
>>08649
Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв. Как ты узнал?
> Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв.
То есть кроме стокового и MPV ничего нет? А как же MPC, тот же "потный даун", ну или VLC в конце концов? Мне казалось что этих плееров у вас там хоть жопой жуй, и выбирать можно по симпатичности GUI и нескучным обоям.
Хочу перекодировать видео в вебм, но 1. чтоб видео, которые разрешением больше указанного, сжимались в габаритах, 2. чтоб они не растягивались.
К примеру, есть много файлов в 4К, и их надо довести до 720р / или же файлы 4000х4000, и их тоже надо уменьшить, допустим до 500х500.
Как делать?
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
Моя команда для кодирование в 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 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Моя команда для кодирование в 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 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
> дополнительный аудиодорожки проебываются
> встроенные сабы проебываются
> метаинфо проебывается
> ненужно1кодек
говно/10
> Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
Нихуя подобного
> -strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
Не нужно давно, это для ффмпег раньше только
Открывает у меня.
>Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
В чем проблема выставить не в секундах?
>Нихуя подобного
Вообще-то он прав. Выставить в секундах можно в av1enc. В ffmpeg ставить только по старому, значением.
>> дополнительный аудиодорожки проебываются
Озвучки мне не нужны, но они обычно отдельным файлом лежат. Комментарии от создателей на японском мне тоже не нужны. Остаются дорожки в 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
>В чем проблема выставить не в секундах?
Не знаю. Когда читал, забыл видимо, что в секунде всегда одинаковое количество кадров.
> Сжимает лучше x265, разве нет?
Нет? позиционировался и продолжает как улучшение x264. Да, лучше чем x264. x265 - нет, в лучшем случае на уровне. И уж точно в разы медленней и ресурсоемче.
>
Чего тогда рейт реквестируешь если сугубо для твоих хотелок и задач однострочник?
>Вообще, отдельный энкодер лучше комбайна, как минимум в теории.
По сути не лучше, потому что в ffmpeg есть встроенные плюшки по типу фильтров, скэйлингов и прочего. А параметры самого энкодера легко вписываются в -svtav1-params.
> Нет? позиционировался и продолжает как улучшение x264.
Ты имел в виду VP9?
Ну так-то он чуть лучше HEVC, но ты попробуй заведи HEVC в хроме или фуррифоксе.
Ичо что там сказано, есть параметр --svt-params keyint:10s вроде в прошлый раз работало. Пайпинг это полнейшая хуйня всегда
Ну в смысле не VP9 а AV1.
А VP9 да, это конкурент H264, с вразы более медленным временем кодирования чем x264, ненужный нигде кроме кодирования на low-end битрейтах.
По факту же, если скорость кодирования не учитывать.
Даже дефолтный средний vp9 самый тяжелый hevc вроде как обгоняет...
Сравнивать надо не --cpu-used 6 с --preset placebo, а качество изображения, полученное за одинаковое время кадра.
>Пайпинг это полнейшая хуйня всегда
Почему? Неудобно может быть, согласен - команды длинные. И если команду нужно встроить куда-то, то вообще не вариант.
> полученное за одинаковое время
Тогда победит h264 и svt, если время малое, и что-то потяжелея, если время больше.
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Команда для 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.
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-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 секунд по моим наблюдениям. Хотя должно быть ровно наоборот - больше ключевых кадров = больше вес файла.
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
Да, посмотрел на другую часть картинки и заметил.
Как же тогда сжимать видео, чтобы без потери деталей?
Зачем тогда этот тред нужен, если здесь предлагают "оставить как есть" и "раздуть до 10 мбит/с"?
320x180, 127:23
Это залётыши. Тру юзеры ффмпега смотрят фильмы только так.
Шакал Квадратович, добро пожаловать!
А может кто-то загрузить и через svt такое сделать на 20 мб, для теста?
У меня просто мобилка, 200 кбит/с.
>изрядная дрисня вероятно будет получаться
Вероятно. По идее от битрейта зависит, а битрейт динамически выставляется crf - чем загруженнее сцена, тем больше на неё битрейт.
Надеюсь, что всё-таки проблема тех скриншотов из-за чрезмерного шума, и в современных тайтлах, где шума нет, или незначительно мало, svtav1 будет кодировать намного лучше. За сегодняшний день я изрядно огорчился в способностях кодеков, думал, сожму раз эдак в 6 без видимых глазу потерь, но нет. Хотя с предыдущим тайтлом получилось сжать без видимых потерь, или может я слишком мало сцен там сравнивал.
> ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
О каком "баттле" может идти речь, если VVC не поддерживается в mpv, только в васянской сборке https://github.com/MartinEesmaa/VVCEasy ? В других плеерах тоже не поддерживается, только через мокрописи-дополнения. И в ffmpeg его нет. Хуйня сырая в общем, ждём.
> Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
Именно.
>>09345
Какой вопрос — такой ответ. Хотите visually lossless — соблюдайте заветы торентоблядей. x264, пердолинг с параметрами на уровне пресета placebo и битрейты как половина от блюрея ждут вас.
Хотите сжатия? Минимального размера при максимальной эффективности? Тогда выбирайте подходящий для вас CRF, устраивающий вас пресет или --cpu-used, и вперёд. И не надо ни у кого спрашивать, какой CRF лучше. Сам сравни и выбери наилучший для тебя.
Я не смотрю видео с мобилы.
Инфа из прошлого треда.
>Пресет 8 в aom
У aom есть пресеты? А что ещё у него есть? Хочу увидеть документацию по всем параметрам.
Когда у тебя бан в гугле истекает?
https://github.com/AOMediaCodec/community/wiki/Advanced-Command-Line-Options
https://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1
Ну и где там "preset"? Поиск на странице дал 0 результатов, нет там этого слова.
>ffmpeg.org
Не открывается.
Хороший кодек. Но я бы предпочитаю кодек WD.
А как таким кодеком шебмы на 2ch.hk заливать?
Варианты для угадывания:
libsvtav1 c -preset 4
libaom-av1 с -cpu-used 8
libsvtav1 c -preset 5
Ссылка на запароленный архив, в котором содержится информация о том, где какой скрин и какие конкретно команды использовались, а так же затраченное время:
https://litter.catbox.moe/4vdayc.7z
Сегодня в 22:00 по МСК скину пароль. Или завтра, смотря как получится.
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
>что при одинаковом времени кодирования
При одинаковом времени кодирования aom не работает. Можешь показать при каких настройках aom сможет кодировать 1280х720х60 в реальном времени? Или хотя бы со скоростью 0.5?
Болезный, тебе зачем на процессоре av1 кодировать в реалтайме? Жди хардверных энкодеров на видеокартах, ими и кодируй с большими битрейтами, если до пизды нужно кодировать в ав1. А что же касается непосредственно вопроса, то aom не может кодировать в реалтайме. А то, что кодирует в реалтайме svt - мыло мыльнейшее.
Чтобы ты спросил.
Меня не интересуют кодеры работающие со скоростью меньше 0.3.
Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.
>мыло мыльнейшее.
Всё ещё лучше реалтаймовых vp9/h264/h265 при том же битрейте.
>3
ты хочешь что у людей глаза к хуям вытекли. Пики говно. Нах на мыльном говниме сравнить, тем более без деталей,
480x480, 2:17
спасибо, теперь буду превращать дум-метал в танцевальную музыку.
Ну что, давайте присвоим этим секциям номер, слева-направо сверху-вниз
Про кадр 1: секция 2 пожата наиболее грубо, ставлю на пресет 5. Секция 4 пожата получше, но всё ещё грубо. Ставлю на пресет 4. Лучше всего выглядит как по мне секция 3, ставлю на libaom.
Кадр 2: ты включил Grain syntesis? Но он здесь не нужен. В исходнике нету шумов, только градиенты. Соответственно наиболее выигрышной стратегией будет просто дать ему замылить, может так он сделает градиенты ещё плавнее и удалит наконец этот бандинг.
Кадр 3: в секции 2 я отчётливо вижу артефакты работы такой фишки AV1 как восстановление цвета из яркостного канала. Прям блоки резко меняющихся цветов повылазили. Ничего не изменилось, ставки по прежнему на 5-м пресете.
Между кадром в 4-й и 3-й секции разницы беглым взглядом не вижу. Ставки не меняються, просто как факт что разница не очевидна.
Кадр 4: бандинг, бандинг, бандинг. Везде бандинг кроме исходника. Скажи честно, ты его в 8 бит сжимал? Впрочем, даже если в 10, не удивлюсь. Но с этим бандингом надо бороться. Даже не знаю как это сделать не раздувая битрейт. Я даже сомневаюсь что 12 бит уберет бандинг. Может сгладит границы, и контуры цветовых переходов станут выглядеть аккуратнее, но вот как забороть бандинг насовсем не знаю.
А scaletempo2?
> исхода баттла VVC vs AV1
О каком баттле идёт речь? Как всегда, VVC aka H.266 займёт место на 8K HDR блуреях, а AV1 как свободный от патентов на YT/интернет видео. AV1 нужно скорее с H.265 сравнивать, который, к слову, уже внедрили в Сафари и в Хром. Спустя 10 лет может и выкатят кодек, который сопоставим с VVC, но сейчас мощи H.265 избыточны. AV1 как был свободным мыльцом так и останется, не в тот состоянии, чтобы с проприетарными кодеками тягаться.
> Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.
У тебя неправильная формула. Стоимость транскодирования определяется по формуле:
стоимость транскодирования = время затраченное на транскодирование / (объём информации * срок хранения информации).
Иначе говоря, если ты хочешь сохранить значительный объём информации на долгий срок, то транскодирование безусловно выгодно.
Например, у тебя есть 200 Гб видео, которое ты хочешь сохранить у себя навсегда. Допустим тебе придётся затратить месяц на транскодирование всех этих видео. Что выгоднее, транскодировать месяц и получить 100 Гб информации заместо 200 Гб, которые ты будешь хранить годами, или таскать с собой все 200 Гб переливая их с одного HDD на другой + регулярные бекапы на чёрный день?
Ты ещё пятый кадр пропустил, он постом ниже.
>Скажи честно, ты его в 8 бит сжимал?
Да, все видео были сжаты в 8 бит, и на то, что я не пожал в 10 бит, есть несколько причин.
Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Вторая заключается в том, что мы сравниваем между собой не исходник с кодеком, а кодек с кодеком. Из этого вытекает, что если битность одинаковая, то разницы по качеству из-за несовпадающей битности в этом случае быть не должно. Но я внутрь не лез, так что это может быть притянуто за уши. Один кодек может утилизировать 10 бит лучше, чем другой. Или наоборот, какой-то кодек лучше себя проявляет именно в 8 бит.
И третья следует из второй, чтобы посмотреть на реальную разницу между 10 бит и 8 бит с разными пресетами и энкодерами, нужно было бы делать ещё больше тестовых картинок, на что ни я, ни файловые лимиты на доске ещё пока не готовы.
>>09616
Увы, у меня таких футажей нет, откуда брать - не знаю, а сервисами со стоками я не пользуюсь.
> Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Должны, ибо находятся в одном и том-же профиле — стандартном. Лишь для 12 бит нужно активировать high profile.
И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
Только один пока решился расписать что-то, видимо придется ждать до завтра.
А если меня не интересуют отчетливые голоса на битрейтах картошки, а интересует сохранность всех слышимых деталей до 20-22 кГц, какой мне кодек звука использовать?
Ну и зачем тебе этот кодек когда он ещё толком ничем не поддерживается?
Есть Opus, есть AAC, есть Vorbis в конце концов. Выбирай любой который тебе больше нравиться.
С аас и огг также? Кто из них пизже? Для огг aotuv еще актуален или есть что-то пизже? Или может уже оригинальный libvorbis не хуже?
У опуса я так понял до сих пор плохая совместимость? Что-то круче него не придумали еще?
У AAC почти так-же. AAC не поддерживают только китайские MP3 плееры, китайские наушники с функцией mp3 плеера, ну и какой-нибудь музейный раритет. Даже старые кнопочные телефоны поддерживают AAC LC.
Opus открывается на любом более менее актуальном смартфоне. Если у тебя остался старый едва работающий смартфон на Android 4 и младше, то у тебя есть выбор между AAC и Vorbis.
>везде
В пизде.
Обзаведись портативным устройством под бюджет, софтовым плеером на вкус, и будет тебе настоящее везде. Mp3 по факту устарел, ему не место в 2022 году ни под каким соусом. Гоните и насмехайтесь над теми, кто в него сжимает. Не место, так же как и огрызкам, которые ничего современные не поддерживают.
Пароль от архива: 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
То есть я не угадал ни в одном из случаев.
Худшим оказался libaom с cpu-used 8. Отличное разоблачение мифа, однако.
Лучшим оказался svt1av1 с пресетом 4, что в общем то логично. Кстати, нужно сравнить svtav1 preset 4 с aomenc cpu-used 4 запущенным через av1an.
Чем он лучше опуса?
>можно в него покодировать
Кодировать можно, а декодировать - хуй. Поэтому
>Я не пойму vvc вышел или нет
Нет, не вышел.
>Кодировать можно, а декодировать - хуй. Поэтому
Да ну. Есть же софтверный плеер какой-нибудь. Хотя пока в ffmpeg не запихнут, так и не будет наверное. Потому что почти все плееры юзают ffmpeg.
>Нет, не вышел.
Посмотрел, вышел то еще в 2020 по сути. https://github.com/fraunhoferhhi/vvenc. Уже версия 1.6.
Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
>Есть же софтверный плеер какой-нибудь
"Какой-нибудь" - ключевое слово. По факту никакой. Ни mpv, ни ffmpeg, ни конусы и дауны, вангую, тоже.
>Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
А потом что? Чем открывать будешь?
vlc плагин какой-то есть https://code.videolan.org/videolan/vlc/-/issues/27055
но у меня не получается его завести
есть еще tencent O266, но мне лень компилить сурс с помощью докера.
Беда прям какая-то, за 2 года могли и допилить.
Куда спешишь? Расслабься, не уйдёт от тебя нескодированное видео, скодируешь, когда будут декодеры.
Так я уже скодировал. 2 секунды в 60 фпс, 210 фреймов. Судя по гитхабу пресет slow чуть медленнее пресета x265 placebo. В общем, у них там работа ведется, и кодек реально очень хорошо оптимизируется, в сравнении с прошлыми версиями.
Можно сбилдить vlc с поддержкой vvdec, но снова лень чет разворачивать всё.
хз скомпилить самому с libvvdec
> 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.
Ну и кому нужен такой кодек? Гуглу такой кодек точно не нужен. Есть варианты?
Получается, что av1 эффективнее x265? Ну, по личным наблюдениям, транскод в x265 даёт очень хорошую сохранность деталям при небольшом уменьшении размера, а av1, как ты не пыхти, будет мылом, но весит мало. Хотя в некоторых сценах и с некоторым материалом av1 не показывает никакой потери деталей, только убирает шум (шум=избыточность).
x265 выглядит чётче потому-что там предусмотрены специальные психовизуальные оптимизации которые увеличивают погрешность при кодировании, но улучшают восприятие картинки. Мне эти оптимизации уже выходили боком, когда я кодировал плавные градиенты на тёмном фоне, они превращались в блочно пиксельное нечто — пришлось вручную уменьшать psy-rd.
У aomenc с этими техниками беда — он по дефолту тюнит под PSNR, а с другими метриками у него какие-то непонятки: то их надо включать в билд, то они замедляют кодирование… Говорят есть ещё форк psyaom, не помню как именно он назывался, но мне лень пердолиться с ним, тем более что меня и ванильный aomenc устраивает.
Что это за пиздец? На каком разрешении, на каких скоростях и прочая и прочая
> Ну и кому нужен такой кодек
А кому нужно что-то выше h264? Тем, у кого проблемки с шириной канала(ограничение на размер прикрепа в посте)/сверхвысокие разрешения, в которых h264 не эффективен, ввиду малого размера блоков, для 1080p это всё пустое баловство и 60% большей эффективности, при сравнимом качестве и адекватном битрейте там наберётся едва ли.
Что vp9, что av1 мылит я ебал. Даже в 4:4:4 деталей не остается, в сравнении с x264.
чел это тесты с декабря 20 года, после 2-3 месяцов выхода vvc.
https://github.com/fraunhoferhhi/vvenc/wiki/Encoder-Performance
Про психовизуальное восприятие не знал. Градиенты не кодировал, сказать не могу.
>он по дефолту тюнит под PSNR
PSNR весит чуть меньше, но на глаз ощутимо хуже чем VQ (--tune 0). Я ещё удивился, почему его по дефолту не ставят.
>а с другими метриками
метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
>то они замедляют кодирование
Разве?
>Говорят есть ещё форк psyaom
Не слышал о таком. Малопопулярные форки доставляют много проблем - мало кто ловит ошибки в них и проводит тесты.
> метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
Я про aomenc, если что.
> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> CQ и остальные выглядят хуже потому что предназначены для другого и поэтому не рекомендуются!
Для чего они предназначены?
Если crf повышает значение в динамичных сценах, то почему в них наоборот выше битрейт, чем в статичных?
Тогда это будет режим с постоянным квантователем, и весить такой файл будет больше.
> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> Указаны два параметра которые рекомендуются в руководстве для повышения качества видео.
Ты сам разбирался, что они значат, или просто на авторитетный источник ссылаешься (он не открывается, кстати)? Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше при прочих равных. По качеству никакой разницы, всё равно CRF 35.
В смысле не открывается
Ну да, ссылаюсь. Параметры из документаций официальных набирал, и по опыту.
> Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше
Серьёзно, можешь показать пример? Странно
Album
[04:20] 1. Artist - Song
с помощью ffprobe или ffmpeg?
ХЗ. Тут с регулярками баловаться надо, а где и как это делать что-бы получить текстовик не знаю.
> но там был патч
Да не было там ни хуя.
(Или покажи, где он был.)
>>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 года.
> но там был патч
Да не было там ни хуя.
(Или покажи, где он был.)
>>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 года.
> > Когда же декодер добавят в FFmpeg?
> Когда закончится срок дѣйствія патента.
Нахер столько ждать. Лучше забыть и не вспоминать.
>под Windows только что ускорили ШЕСТИКРАТНО
Почему числа под люниксам в четыре раза больше. Как ос связана со скоростью кодирования?
>такие адски заумныя, как >>05534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется
>сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов
Действительно, зачем нужны адские заумия для понтующихся имитацией дореволюционной орфографии, особенно, если они не понимают как работает ДКП и прочие интегральные ортогональные преобразования.
Что это за картинка, почему на винде так медленно?
Есть пейлист на ютубе с видео уроками. Самое важное там это аудио, а видео это по сути набор слайдов.
Хочется пейлист себе сохранить, но так чтобы он не занимал много места.
Как быть в такой ситуации? Слишком низкое качество картинки может не подойти т.к. там текст и потом его не поймёшь.
GOP 9999
Для подтверждения что он не наебал с ответами, в старом архиве то же самое. Ты конкурсы в интернете никогда не видел? Без подобного пруфа организатор может изменить ответы по своему желанию.
>а видео это по сути набор слайдов.
-vf mpdecimate
Если два последовательных кадра дублируются, оно расходует почти 0 битрейта.
Никак. Потому что mp4 не нужен, это говноформат без поддержки кодеков и с двойной записью на диск ради быстрого запуска (-movflags +faststart).
Можешь рассказать почему такая задача возникла?
Таккак вконтейнерахMP4 только https://en.wikipedia.org/wiki/MPEG-4_Part_17 поддерживается вкачестве форматасубтитров, топоневоле придётся искать переводчик изASS вэтотформат.
(Яотаком незнаю, напримѣръ.)
Пиздец, невозможно общаться нормально.
Мне кажется только рядом с файлом с таким же именем положить, а плеер сам подхватит.
Может быть, остальной софт имеет все те же функции и кодеки, что ffmpeg, и такой же бесплатный?
Они уже на ютубчики сразу должны быть пережаты как надо, чтобы минимум места занимать. Гугл же не тупые.
В принципе да, это тоже может подойти. Скачал длинный видос 30мин+ и не в самом лучшем качестве, но смотрибельный, вышло 31мб.
Оно пересжато как надо им, максимально некачественно, с минимальным качеством и размером. Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
>Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
И как ты это сделаешь, сверхразум? Как будто этого никто не знает.
Ютуб транскодирует асиками. Транскод асиками даёт возможность транскодировать очень быстро, но не очень качественно.
Он имеет ввиду, что исходников от гугла ты не допросишься.
Асики от nvidia едва доползли до однопрогодного -preset medium, если говорить о h264. Новейшие асики в видяхах от Intel кодируют AV1 с эффективностью аналогичной x264 -preset veryslow. Для реалтайма может и прорыв, но с кодированием на CPU на медленных настройках не сравниться.
Ты думаешь там кто-то что-то кодирует на асиках потребительских видеокарт?
Допустим, когда после -r я ставлю 10, то всё нормально
А когда 1 -- остаётся десяток-другой тишины.
Но во втором случае всегда намного меньше веса.
Как собирать шебмы с еденицей фпс и чтобы выходило ровно по времени?
Пример команды:
ffmpeg -r Х -loop 1 -i картинка -i музыка.wav -c:a libopus -b:a 128K -c:v libvpx-vp9 -strict -2 -shortest выход.webm
По крайне мере стоит попробовать явно указать -t
Если это поможет и если автоматизировать - я бы скрипт на питоне сделал, который получает длительность и вписывает её. Может быть есть способ как-то через командную строку указать, вроде -shortest - я без понятия.
Ещё есть же кодеки поддерживающие переменный fps, думаю через это можно в конце добавить кадр с длительностью нужной.
Это баг даже не -r вроде, а самого ffmpeg когда пытаешься залупить картинку. Хотя мб ты нашел причину, просто ставь -t под длительность музыки.
> -g 9999
Зачем? Я с тем же успехом могу тупо один фрейм с картинкой закодировать. Что так что этак прокрутка идёт по пизде.
> Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен?
Он все еще в активной разработке.
> Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
Используй.
>Он все еще в активной разработке.
Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
>tduration(input/output)
> When used as an input option (before-i),
> limit thedurationof data read from the input file.
Вопрос снят, я жопочтец.
> Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
Ядро Linux пилят 20+ лет, перешагнуло 6.0.0, все еще в активной разработке. Дальше что?
Хомо сапиенс эволюционировал уже как 50 тысяч лет, изобрел спермерочку и всё ещё активно эволюционирует. Дальше что?
В аутпут лучше в параметры кодироваания видео после основных.
avidemux резка с ключевого кадра.
В правом нижнем углу формы ввода написано для каждой доски.
> -pix_fmt yuv420p
Не нужна субдискретизация при такой частоте кадров.
Это экономия на спичках.
Дело скорее в совместимости, охват утюгов, которые декодируют 420 больше.
и ещё ест трабла, первые 1-2 минуты видоса очень пиксельные, потом всё идеально, как фиксить? без поднятия битрейта желательно, конверчу на долгое хранение
Там одинаковые настройки и только названия разные?
Батник, не? Или скрипт твоей ос, или просто на питоне через subprocess?
не там есть траблы с сабами и аудио, надо вручную выбирать дорожки, это заёбно но я составляю такие списки заранее и потом по одной серии конверчу, я хз даже как через батник, типа каждую серию в отдельный тхт и как то потоком поставить?
Не кодировать в CBR. Лучше поставь двухпроходный VBR.
Ты идиот? Гифки это древний формат с древними принципами сжатия. И вообще гифкам место на свалке истории. Жаль им до сих пор не придумали адекватной замены.
Но сравнивать древний формат из восьмидесятых с современными видеокодеками это конечно шиза.
echo "команда 1" && echo "команда 2"
Потому что гиф это ряд картинок jpg буквально. допустим jpg весит 500кб в ней 60 кадров всего. Вот и умножай сколько получится - 30мб
До меня правда только что начало доходить, что в исходнике кадры пожаты 264-м, в то время как гиф ничего не жмет сам по себе, только если скажешь ффмпегу жать твою гифку с доп. параметрами.
Обязательно меня идиотом называть, если мне раз в сто лет пришло сделать такую штуку и я сходу не разобрался, что к чему? Почему жизнь ко мне так несправедлива и жестока.
Тебе не нужны гифки для сжатия. Методы компрессии формата GIF устарели, и не могут быть использованы для транскодирования видео в сколько нибудь приемлемом качестве.
Ну у джипега перед гифкой есть преимущество: ДКП. А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
> А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Потому что GIF внезапно loseless (LZW). В отличие от.
>надо вручную выбирать дорожки
Совсем вручную? Ну, если там разумное количество файлов, то просто скопировать строчку нужное число раз и вставлять номера дорожки. Если безумное, то ты всё-равно на ручной просмотр времени много потратишь.
Но даже без скриптов ты можешь просто список файлов сделать с номерами, и через замену заменить разделители на остальные параметры.
>типа каждую серию в отдельный тхт и как то потоком поставить?
Какой txt?
Просто кучу команд пишешь и запускаешь, оно их само по очереди все сделает, ещё можешь загуглить что такое shift и %1 в батниках, ещё быстрее сделаешь. Если хочешь вместе, то нужно либо команду для cmd запуска в отдельном потоке искать, либо через питон. И ещё всё зависнет, так как после десяти одновременных экземпляров даже мышка будет плохо двигаться.
Пробуй делать APNG. Многие забывают про этот кошерный формат, в то время как слово гифка стало маркером быдла, как и эмэрзе.
> APNG
Те же методы сжатия что и у GIF. Единственное преимущество перед GIF — поддержка 24-битного цвета.
> WEBP
Не знаю чего там напридумали инженеры из гугла, но WEBM из VP8 будет весить меньше, чем WEBP. Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.
А если пережать в H264/VP9, то полученный файл будет в разы меньше гифки. Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
>Единственное преимущество перед 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%.
> Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
Вроде бы какой-то флаг кодирования есть в одном из форматов...
> Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз
Запости, хочу глянуть.
> А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.
VP8 да, Анимированный WEBP не факт что вообще влезет в твои лимиты. Опять же, ты даже не пробовал сжимать.
> Хотя если тебе надо постить на двачах
А что с ними ещё делать? Коллекционировать и рассматривать долгими зимними вечерами? И эти форматы постятся не только на двачах, потому странно хранить изображения в форматах, которые используют 3.5 софтовых калеки.
упд. Мда кал нельзя запостить, еще и поддержку mp3 пидорнули.
Зато новый движок не падает постоянно с 502 Плохие Ворота. Хотя нет, подождите...
https://www.youtube.com/watch?v=dap5lEuS5uM
Ну так пока yt-dlp одуплится, пока mpv всё это прожуёт, секунд 5 и пройдёт. Сам попробуй введи команды в консольку и посмотри сколько по времени весь процесс займёт.
На линуксе кстати быстрее всё происходит.
Так это же ютубовское ограничение скорее, а не сишки или ещё чего.
>>13619
Во-первых, немного полегче контейнер, во-вторых предположу что специально.
Написать что бравзер поддерживает webm - норм. А написать браузер поддерживает mkv, но только видеодорожки форматов h264, vp8, ... и аудиодорожки форматов ... - это намного недружелюбнее для пользователей.
Спроси у обывателя какие форматы поддерживает его видео плеер - он скажет что mp4, avi и что там ещё бывает. А при упоминании avc или h264 скажет что первый раз слышит.
Что специально? Ну да, я и говорю, что не случайно, только зачем делать матрёшку, которая умеет меньше оригинала?
С масштабом 100% уже выглядят почти одинаково. Но всё-равно отличаются - по краям смещение кадра на пару пикселей, как будто обрезали. И сама область с картинкой на чёрном фоне сдвинута на пару пикселей.
Potplayer ytdlp открывает сразу за 1-2 сек, но в общем всё вместе пока ytdlp догрузит тоже 5 сек.
Вряд ли там галочка есть, но вроде бы там была строчка дополнительных параметров для ffmpeg, вот туда попробуй что-то вроде этого дописать.
https://ffmpeg.org/ffmpeg-filters.html#toc-dynaudnorm
Ещё фильтр loudnorm поищи.
Пробуй пока не получится, строка ретарда вроде как напрямую скармливается ффмпегу.
Хм, может внутренний ffmpeg нужно поменять на более новый.
Там же при сборке можно отключить не нужное, может быть и этот фильтр отключили...
Не знаю что посоветовать, кроме как сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный.
>>13892
Нет, ему же прямо написало, что оно поняло название фильтра, но фильтра такого не обнаружило.
> Хм, может внутренний ffmpeg нужно поменять на более новый.
а как?
> сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный
нихуя не получается, ничего не понимаю...
Пиши подробности про XnView.
Он у тебя классический или XnView MP?
>>13426
> APNG
> Те же методы сжатия что и у GIF.
Бредятина!
Во-первых, DEFLATE — это не LZW.
Во-вторых, используются предикторы.
> Единственное преимущество перед GIF — поддержка 24-битного цвета.
Также ерунда: во-первых, не единственное, а во-вторых, PNG поддерживает и 48-битный цвѣтъ.
>XnView MP
Да, он.
>Пиши подробности про XnView.
Да я свою претензию уже написал. Ещё могу сказать, что он, имхо, запускается дольше, и если нажать не ту клавишу, то вместо выхода из программы откроешь интерфейс эдакого проводника вместе с картинкой.
> Во-первых, DEFLATE — это не LZW.
Да похуй. Lossless сжатие это последнее что меня интересует.
> Во-вторых, используются предикторы.
Которые предсказывают лишь 1 пиксел от 3-x или 4-x ближайших соседних пикселей, в противовес тому же VP8 где предсказывается макроблок из крайних пикселей соседних макроблоков. И это я ещё не говорю про AV1 где эти блоки могут быть переменного размера и к тому же могут иметь неквадратную форму.
Он еще и качает с конца как бы, вот что хуже всего. Сейчас был стрим на 1 час и 40 мин, скачал 50 мин, и получается первых 50 минут нет.
Записать с помощью mpv.
stream-record, или dump-cache команды.
https://mpv.io/manual/master/#options-stream-record
https://mpv.io/manual/master/#command-interface-dump-cache
Какой из гуев сегодня жив?
Немного полистал поиск на гитхабе, очень много тех кто уже по 2-3 года не обновлялся
handbrake
850x576, 0:12
Принимает на вход текстовый файл и картинку, результат видите.
Изначально увидел подобное в тиктоке/телеге, на каналах, где читают с реддита или всякие новости. Но там было так, что текст сразу весь на экране, я решил сделать, чтоб "типа" со скоростью чтения он проявлялся. В итоге год назад сделал, но нигде так и не использовал, сейчас вот вспомнил. Вроде, вполне неплохо, особенно если вместо стандартного синтезатора использовать качественный.
Можно генерить сотни, тысячи таких текстовых видосов батчем.
Вопрос. Где это можно использовать?
Думал сделать канал в телеге или тиктоке, чтоб туда автоматически загружался каждый день видос, допустим, с топ новостью для из какого-то источника.. На этом идеи акончились.
Подкиншь мыслишек, анон?
Не понравилось?
В бесконечном цикле скачиваю следующую песню с ютуба, стримлю ее в буфер, потом из буфера стримлю уже на ютуб.
Чуть-чуть идет, но потом прерывается..
Не могу понять, что за "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
Пайп в принципе через жопу работает как-то. Пытался последний раз, а он не в какую.
есть видео 1280x720.mp4 сделал гифку 300x300, в гифке черные полосы по бокам как покифксить?
откати апдейт
понял, спасибо, учусь по статье https://video.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffmpeg
может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
> может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
Делай кроп хандбраке, там есть удобное превью с возможностью указать кроп on-the-fly. Не еби себе мозги с ффмпежей, он не создан для динамического редактирования видео.
Сделай скриншот кадра с хорошо различимой границей между видео и чёрной полосой.
Открывай в любом графическом редакторе (хоть в фотошопе, хоть в гимпе, не важно, главное в пеинте не открывай). Приближаешь на 400+ %. Берешь инструмент линейка, ставишь горизонтально на границах с контентом и полосой, после чего берёшь горизонтальные направляющие и ставишь направляющие на линейку. У тебя должно получиться 2 горизонтальные направляющие.
Снова берёшь линейку и меряешь пиксели от верхнего угла до верхней направляющей. Это и будет твой «x». Потом меряешь линейкой расстояние от верхней направляющей до нижней направляющей. Это будет твой «h».
> Это и будет твой «y»
Извините, опечатался. Х это всё таки для обрезки по горизонтали, а не по вертикали. Так что это будет не X а Y.
ffmpeg -hide_banner -ss X -i in.mkv -frames:v 1 -vf cropdetect -f null -
, где X - время кадра с черными полосами.
Ищешь в выводе строчку где написано crop=..., копируешь это, вставляешь в фильтры, Профит.
Я в paint.net на скриншоте смотрю координаты для кропа.
Например: https://pikabu.ru/story/passazhirka_kinula_taksista_na_1700r_9580107
Наверно, в него кодируются ролики только из самых популярных постов, как и в случае в ютюбом.
Открой в mpv. Алсо, там даже в названии файла av1. Сохранил – MediaInfo показывает av1. Как ты его в vp9-то умудрился открыть?
У меня Polaris. Он не то что av1, даже vp9 не декодирует. И да, при чём здесь это?
У меня то же самое даже на пресете 5, на обычном ноутбучном процессоре. А на пресете 7 в разы быстрее libvpx-vp9, при качестве немного выше.
Вообще есть же ещё svt-vp9 какой-то...
: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
Мышкой выделяешь файлы и на батник перетаскиваешь, все строчки кроме длинной чтобы открывать несколько файлов. Но это не сработает, если у тебя несколько аудиодорожек или ещё что-то сложное в видео.
Большое спасибо.
Кстати твоя команда даже лучше дефолтной, аж в 2 раза файл меньше весит на выходе.
Как научиться писать такие батники?
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере 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 моментально детектит какую-то проблему с файлом и сходит с ума?
Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере 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 моментально детектит какую-то проблему с файлом и сходит с ума?
Я заметил такое поведение в utorrent. Когда добавляю новый торрент с многосерийным сериалом, сначала ставлю приоритет файлов по порядку, от 15 (высокий) до 1 (низкий), чтобы серии скачивались по порядку от первой и так далее. Но когда торрент стартует, utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце, только после этого начинается нормальная закачка с приоритетом на первый файл как было задано.
Это специальная фича сделанная для превью, не знаю в каком конкретно софте, но по всей видимости видео так устроено, что для открытия требуется не только начало, но и конец. И это настолько известный факт, что специально запиливают в криентах такую фичу качать в первую очередь начало и конец.
>utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце
Такое со всеми файлами, включая последний файл?
Просто начало N-го файла лежит в том же куске торрента, что и конец N-1-го, так что при скачивании начала одного неминуемо скачается и конец предыдущего (кроме редких случаев, когда граница файлов совпала с границами кусков).
Да, со всеми. Я специально один раз проследил, в utorrent в списке файлов и есть и диаграмма кусков, так что видно как клиент запрашивает и скачивает граничные все подряд, и пока не закончит этот процесс нормальная загрузка не начинается.
Насчет неминуемой скачки согласен, просто такая формулировка "начало и конец" была когда случайно встретил упоминание этой фичи в интернете, и кажется для другого клиента. Просто так совпало, что заметил такое странное поведение у себя, а потом встретил упоминание как фичу.
А, насчет последнего может ты и прав, правда там как раз была озвучка, которую я исключил из загрузок, но вроде последний таки не догрузился, или по крайней мере я припоминаю что висел некоторое время незагруженный.
>аж в 2 раза файл меньше весит на выходе.
Ясен хер, там crf 30 стоит, но качество никакого не будет с ним.
>аж в 2 раза файл меньше весит на выходе.
А если 30 заменить на 40 - то будет в четыре раза меньше или типо того, и это ещё от исходного файла зависит.
Прочитать справку по ffmpeg, и справку по bat-файлам, или просто загуглить нужный тебе функционал.
У меня точно такой же скрипт на питоне есть, для более сложной обработки файлов, на который можно как на батник скидывать. Я не знаю есть ли такой функционал у файлменеджера люникса - но если есть, то можно конечно, потому что питон там точно работает, а что с местными батниками (там sh-скрипты вроде бы) - я не знаю.
Я на питоне себе напердолил скрипт, который рендерит все видео, которые лежат в одной с ним папке. Не то же самое, но как вариант.
Нет. Там надо открывать консоль, ручками прописывать название скрипта, а уже потом в окно консоли скидывать сам файл, после чего запустить.
https://ffmpeg.org/ffmpeg.html#Advanced-options
-map_metadata -1 стирает метаданные из контейнера и стримов.
-map_chapters -1 должно стирать главы, но на деле получается пикрелейтед №2 в mediainfo глав нет, но осталось обрезанное меню навигации, а в видеоплеере пикрелейтед №3 ебаные главы до сих пор на месте.
КАК ЭТО ГОВНО ВЫРЕЗАТЬ ОДНОЙ КОМАНДОЙ?
Можно через -f ffmetadata сделать дамп метаданных, потом поправить их через блокнот и импортировать обратно, но НАХУЯ, ЕСЛИ МНЕ НАДО ПРОСТО ИХ УДАЛИТЬ?
Можно импортировать пустой файл, но это костыль.
КАК ПРОСТО СТЕРЕТЬ ИХ?
удваиваю реквест кста
Ок, я разобрался, нужно добавить
-movflags disable_chpl
И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
С помощью винампа можно, в меню плейлиста.
Может быть добавить флаг -dn? По идее там есть только аудио-видео-субтитры, и ещё некие данные, и вот -dn как раз про них. Может быть.
> И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Объясни.
mkvtoolnix
Для mp4 контейнера chapters для нормальных людей хранятся в формате quicktime, а для заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись, потому что им нужно выделиться из общей массы.
Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
> chapters для нормальных людей хранятся в формате quicktime
> заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись
Что?
>Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Может. Потому-что
>mp4
Конченый, ни на что не способный контейнер без каких-либо преимуществ, который пропихивают срыночные пердиксы из патентной параши MPEG LA и их подсосы.
Зачем повторил моё последнее предложение?
Понятное дело, любые видеоплееры охуевают от этого, и воспроизводят либо аудио, либо видео.
Ффмпега это тоже касается, он если и кодирует, то сохраняет эту длительность.
Так вот, есть ли какой то способ это исправить? Можно ли заставить ффмпег не тащить длительность видео, а составлять её самому?
Пики отклеились.
Ну есть один способ , но он какой-то дебильный, если кто-то знает получше подскажите
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
Пасиба, добрый анон. Правда пришлось ещё видео повернуть, но это просто.
Угу там действительно много вычислений требуется.
Есть кодеки, которые прессую карточку, а процессор уже поменьше - но они отличаются плохим качеством по соотношению размера файла к качеству изображения.
Нуб в треде. Такая команда будет идентична исходнику или нет? Мне бы в идеале распакуя обратно m4a в aif, чтоб спектр вообще был неизменным. Или все таки после этого уже не будет идентичен?
В 99% неизменно, нет только если там какие-то специфичные 32 бит и подобное
Можно проверить такой клмандой:
ffmpeg -i 1.aif -f hash -
ffmpeg -i 1.m4a -f hash -
Если одинаковый хеш то не изменилось
Значит так. Можешь брать сразу тредрипер, и 128 ГБ ОЗУ. Запускаешь на этом av1an, и при правильной настройке он будет загружать сразу все эти потоки, ну и молись чтобы оно не полезло в своп.
Не, ну можно конечно взяьт с алик 2*EPYC 7601, но нафига мне такая дура? По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
>av1an
Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Ну у голого aomenc с паралелизмом дела обстоят не очень. Можно конечно врубить tiles, но это ухудшает качество.
Если ты собираешься запускать голый aomenc, то лучше новых топовых интелов не найти.
Но если тебе нужно расскрыть потенциал твоего проца на максимум, тогда тебе придётся осилить av1an. Так то что av1an, что svt оба делят видео на GOP и кодируют их параллельно.
> По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
Так не бывает. Тут либо файлопомойка, либо сервер нахуй.
>Ну у голого aomenc с паралелизмом дела обстоят не очень.
Действительно... С другой стороны это облегчает выбор, на нужно гнаться за многоядами. Какой-нить 11600k с рук, раскочегареный по одному ядру наверное оптимально зайдёт.
Дешевле всего купить зион с большим количеством донных ядер. Конечно нормальный современный комп лучше справится
>>25255
> Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Переможный костыль для убогого кодировщика которая делит видео на множество маленьких чтоб нагрузить все ядра
В строчке дополнительных параметров указать нужный фильтр (их несколько вроде как) нормализации ffmpeg с нужными параметрами. То есть так же как и в чистом ffmpeg.
Никакого интерфейса для этого может и не быть
Тогда никак. Ограничение интерфейса твоей программы или просто твоей программы, она не может выполнить твою задачу.
Ранее консилиум сжатиешизиков обсуждал данный вопрос. В ходе обсуждений был сделан следующий вывод: лучший способ сжатия видеоархива - купить жёсткий диск.
Ты попросил невозможного, выбери два пункта:
Максимальное качество
Низкий размер
Быстрота кодирования
в 720p crf23-28
я не автор вопроса, но интересен вариант: Максимальное качество+низкий размер - подозреваю что надо в сторону H265 копать, но если кто в теме более детальных параметров для заданной цели, рад был бы узнать
>>26521
интересуют также отличия настроек в зависимости от конента, например если у нас не домашнее кино про немцев, а туториалы, о том как домбить бомбас качать кино про немцев баз смс и регистрации, где много текста на экране и мало динамики, бо то качество в котором кино можно смотреть может быть для текста нечитабельно, скорость кодирования думаю проблемой не будет, при наличии NVENC, и МНОГАЯДЕР у процессора...
Чтобы умереть от старости даже собирать ничего не надо - av1 через libaom на veryslow сгодится.
а профиты то от av1 veryslow будут? так то дурной задачей можно всегда себя нагрузить, вопрос то в профитности затеи, насколько например будет прирост компрессии в сравнении с кодекнейм, ну и без более детального указания параметров тоже вопросы возникают - или мы Лузлесс кодируем или определенное ограничение качества ставим...
>>26533
а здесь немного я не понял прекола, зачем нам xhe-acc с аудио по моему вообще проблем особыхх нету как по мне, и маста аудио дорога занимает на порядок меньше... вопрос еще к воспроизводимости контента возникает, а то можно такого накодировать что ничем не откроется... и какой тогда смысл этого всего...
Потестил AV1 - для него норм кодировщик надо, потому что одни умеют 24 потока заюзать, а другие непонятно чем занимаются во время кодирования и оно капец долгое выходит... но уменьшение размера впечатляет, хотя разница в качестве на глаз заметна даже...
>>26583
тогда остается только HEVC Loseless для качества, ну или с высоким качеством на крайняк... av1 хорош на случай когда и места жалко, но и файл пусть полежит...
Там два енкодера av1 если что. libaom-av1 референсный, был в основном добавлен для тестов. Овердохуя медленный, но жмет как надо. И libsvtav1 - над ним еще активно работают, но в последних версиях ffmpeg (5.1+) он уже довольно прилично работает и шустро.
> хотя разница в качестве на глаз заметна даже...
crf поменьше?
та вроде в 0 до упора (я вообще HANDBRAKE юзал для конвертации, не хочу с терминалом возится на винде), но с 30 мб до 1 сжать это конечно сильное заявление на успех...
по качеству хотя может то HEVC чего намутил, с которым сравнивал, бо HEVC как будто подтянул четкость или контраст, но это не точно...
по факту все экспериментально походу решать надо... так как не все настройки всем подходят...
Побеждает, конечно. Только попробуй найди этот Tencent V265 или Pheonix265, QAV1, чтобы можно было сжимать в него.
Что-то не вкурю почему или 4:1:1 на скрине или 6:1:1 куда ж с такой субдискретизацией сунуться - эт дичь какая-то выходит... И так ли велика разница проприетарщины и опенсорса
В импортных железках? В любом случае, если это н
хардварные имплементации, то они сосут бибарандум у софтовых реализаций.
Мне даже интересно, где они эти hw266 достали и на какой процессере или плеере воспроизводили вообще какой производительностью
В общем, есть около 15000 файлов в mp3 и звук который нужно наложить поверх этих файлов, типа вотермарки которая будет звучать поверх музыки. Как это реализовать массово? Чтобы не вбивать по файлику, а вхуячить папку входа и папку выхода с теми же названиями файлов по итогу?
Если есть более простое решение - буду премного благодарен, поскольку несколько дней гугления ни к чему не привело. Либо я находил программы без описания работы, либо решения которые делают только по одному файлу за раз.
ffmpeg batch av converter, там все есть, и кодирование в твоих настройках, и генерация древа папок из сорса, плюс одновременное кодирование в отличии от обычного ффпмег, либо батник пердоль. Для себя лучше не нашел.
>одновременное кодирование
Параллельное кодирование точнее. Не дописал, что сам кодировал 36к ogg файлов в opus. Довольно быстро сделал в 24 потока.
Что мне потребуется? Я так понимаю, это вполне возможно, если знать что вбить в командную строку.
На телефоне NewPipe без командной строки, на компьютере - да, yt-dlp -F и yt-dlp -x --audio-format=
Однажды сработало, а щас не работает. Стрим рекорд не дает скачать стрим с ограничением по возрасту, а дамп кэш вообще пишет: опция не найдена.
Мой фаворит это порнуха высотой кадра 180. Высокая продолжительность видеоряда, но всё различимо и без квадратов. Хочу так же.
Во-первых есть AV1 который всем его лучше, а во-вторых оба не подходят для указанной задачи, потому что очень любят мылить картинку.
Ну да, так и делают. 320x180 ставят на 25 минут чтобы картинка не сыпалась на квадраты на таких битрейтах. Если просто взять и при том же битрейте поставить 360p, то чёткость от этого не увеличиться, а артефакты полезут со всех щелей.
Сжал только что сохранения для игры Rimworld - 6495 Мб превратились в 56 Мб. Я конечно любитель сжимать сжимаемое, но это уже чересчур.
Чтобы картинка выглядела лучше — нужно потратить больше битрейта. Битрейт определяет количество информации, которое будет закодировано. И поставь ты хоть 1080p, но на 128kbps картинка будет выглядеть мыльным говнищем.
При этом в 1080 она будет выглядеть лучше чем в 240. Потому что у кодировщика есть больше данных, больше разрешение чтоб разгуляться. Могу даже показать пример
Ну давай, показывай пример.
Ожидаемо, там же все сохранения - однотипные XML файлы, к тому же не инкрементальные
Очевидно что формат не одинаков. У многих кодеков есть вагон и маленькая тележка профилей, добавляют их со временем, поэтому в старых железках/софтинах может не быть поддержки. Как в свое время было с 10 бит в h264.
Попробуй youtube dlp. Но я не пробовал.
в этом или прошлом треде было. Через mpv
Снял минуту обс в мкв, 115 мб - конвернтул ффмпг в мп4 - 50мб, двощ все равно не грузит. Что делать?бочку
> мкв
> мп4
> Что делать?
Идти читать что такое контейнеры и кодеки, чем они отличаются, как задавать качество/битрейт в ffmpeg для них, а так же - какие форматы поддерживает двощ.
> (Linux: Firefox based)
Дожили - неграмотные линуксойды домохозяйки.
Задаю конкретный вопрос в целевом треде.
Я всю жизнь занимался совсем другой темой, вот и спросил, а нонейм мне говна вылил, хотя явно мог бы правильные ключи для ффмпг сказать. Пшел нахуй.
> Я всю жизнь занимался совсем другой темой
Пруф несёшь, что не бесполезный кусок говна и не трепло. Тогда подумаем, сказать тебе ключи или нет.
Если ты даже в элементарных вещах в кодировании ничего не понимаешь, значит, несмотря на то что результата ты хочешь и какого получше,вообще не утрудил себя почитать ничего по теме. Сразу побежал требовать чтоб за тебя все сделали зашибись, а ты сидел шиковал на всем готовом. Никакого желания объяснять азы тому кто не желает учиться нет. Качай какой-нибудь WebM for Retards, тебе хватит.
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
Что с этим говном делать? Почему при первом проходе и начале второго не показывает ни номер фрейма, ни время?
Раньше было, а после какой-то обновы перестало показывать. А мне нужно процесс контролировать, проценты выводить. Где мои проценты?
Что значит немного больше? Мне битрейт рассчитать надо.
Например, на одну минуту у тебя уйдёт 2.8 мегабит.
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
Premiere Pro has the worst encoders ON THIS PLANET
Сколько пользовался четвертой версией, всегда так было
> В видеоредакторе.
Да ну. Ты ещё расскажи что Premier Pro умеет рендерить в WEBM. И не просто рендерит, но и поддерживает уникальные особенности этого формата, вроде смены разрешения видеокадра на лету.
Значит не Premier Pro
К премьеру можно подрубить воукодер или даже ффмпег (через костыли). Полгода давился давинчи, заебало врать себе что он не дерьмо собачье. Вернулся на премьер.
Найти детектор потока, расширение для браузера, скорми ссылку в ffmpeg как у меня примерно и запусти. -t и -ss по крайне мере на твитче поддерживаются.
Предположу что youtube-dl справится тоже, скорми ссылку с флагом -F, посмотри даёт ли он форматы. Ещё youtube-dl умеет выдавать ссылку без запуска браузера. Но если загружать прямо через youtube-dl он не умеет обрезать часть стрима до загрузки.
Что-то от bit stream format, наверное.
yt-dlp.exe --username ИМЯ --password ПАРОЛЬ ...
>FFmpeg справляется с данной задачей?
Конечно.
ffmpeg -i video.xyz -i sound.uvw -c copy output.mkv
404x454, 0:03
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"
если гиф, то у меня двухпроходное
только чтобы тупо сэкономить место на hdd. сейчас такие exos на 6 тб каких-то запредельных денег стоят. так что перекодировка экономнее, чем второй покупать
Может просто меньше дрочить? Я картинки то сохранённые второй раз редко открываю, а тут аж порнуху терабайтами пересматривать
Для ускорения этого нужно выбирать best, а не dash, но это 720p всего. А еще вот такую строку:
https://paste.debian.net/plainh/951b739a
Ты же запсукаешь сразу два потока отдельные экстракты видео и аудио, более того - dash на ютубе железно ограниченные скоростью, из-за этого тоже долго, да и то что dl/dlp скомпилированный упакованный exe с тысячами скриптов, пока он расчехлится тоже уходит время.
Зачем вообще кодировать?
Видосы с мобилки.
Мобилка без процессора, потому там часто константный битрейт громадный и сжатие очень условное, чтобы оно успевало в реальном времени кодировать - после перекодирования часто можно без заметных потерь раз в 5-10 пожать.
Шебмы для харкача.
И чё?
порно личное снятое на профессиональную камеру надеюсь? или ты блюреи японские рипаешь?
после того как ты провел тесты на разных битрейтах и выбрал приемлемый для тебя уровень качества?
кстати скиньте софт для таких тестов. я только знаю что сравнивать видосы можно в kinovea (привет из 2004) и ICAT (не поддерживает даже h265 лул)
вот бы новые видеокодеки с беспотерьной совместимостью со старыми как jpeg xl... я недавно нагулил в егоном треде что был такой для пережатия h264 в тот же формат но не особо много экономил.
Это копия, сохраненная 28 января 2023 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.