Главная Юзердоски Каталог Трекер NSFW Настройки

Программы

Ответить в тред Ответить в тред
Check this out!
<<
Назад | Вниз | Каталог | Обновить | Автообновление | 194 38 48
FFmpeg и общий кодирования видео тред №8 /ffmpeg/ Аноним (Microsoft Windows 10: Chromium based) 12/09/22 Пнд 22:37:25 3205384 1
1651073624816.png 400Кб, 2000x2000
2000x2000
FFmpeg и общий кодирования видео тред №8

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

FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.

Скачать тут: https://www.ffmpeg.org/download.html

Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.

Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.

Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.

Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.

Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.

Вики WebM-треда (во многом устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s

Гайд по кодированию от анона из треда №5 (принимается критика, её было много в треде №6): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md

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

Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.hk/s/res/3144406.html
Тред №7: https://2ch.hk/s/res/3181555.html
Аноним (Microsoft Windows 10: Firefox based) 12/09/22 Пнд 23:13:04 3205405 2
>>3202307 →
Бамп.

Мне самому писать или есть с коррекцией перспективы?
Аноним (Microsoft Windows 10: New Opera) 13/09/22 Втр 01:58:37 3205465 3
Надо наложить музыку на картинку, что делать?
Аноним (Microsoft Windows 10: Chromium based) 13/09/22 Втр 10:12:22 3205513 4
Аноним (Linux: Firefox based) 13/09/22 Втр 12:34:07 3205534 5
>>3205329 →
>Не работает ссылка.
Судя по цитате, автор там, пытаясь заигрывать с примитивизацией, искажает реальность совершенно необратимо, до полной потери смысла.

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

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

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

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

>>3205319 →
>-pix_fmt yuv420p10le
>Что это?
В первой строчке это требование декодировать обязательно в цветовое пространство YUV (колориметрические параметры не уточняется, тем не менее, лол) с прореживанием 4:2:0 и разрядностью числовых значений компонент по 10 бит. В большинстве случаев это анимешничьи выебоны.
Аноним (Microsoft Windows 10: Firefox based) 13/09/22 Втр 13:31:48 3205553 6
>>3205534
>- вычисления выполняются с большей точностью
Не очень понятно почему все промежуточные вычисления не делаются в 32 бита, и только конечное представление ужимается в 8-10 или другое случайное количество бит, где может быть как целое число, так и даже своя шкала, по типу что 0b0001 == 0.001, 0b0010 == 0.003, 0b0011 == 0.007 (которая супер-медленная для промежуточных рассчётов, но чуть эффективнее для сохранения) - как будет короче записать, с обычными числами или сохранив ещё и таблицу для нужного количества бит.
Просто по идее разница между 0 и 1, или 3 и 4 на глаз заметнее, чем разница между 245 и 246, если даже тупо в пеинте одну компоненту поменять, так как яркость заметнее изменяется - потому я и предложил шкалу имеющие шаги ниже ближе к нулю.

>И не обязательно с плавающей точкой.
Да я просто как вариант. Процессор вроде бы одинаково быстро умножает.

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

Понял в двух словах вроде бы, спасибо.
Аноним (Linux: Firefox based) 13/09/22 Втр 17:51:08 3205595 7
>>3205553
> Процессор вроде бы одинаково быстро умножает.
Даже самые современные x86_64 работают с целыми разика в полтора быстрее. Плюс умножение и сложений целых и дробных с фиксированным разделителем происходит без потерь, а у дробных с плавающим разделителем с этим ай-ай-ай.

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

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

>в нужном представлении пережимать их сначала в rgb не будет?
Если явно не попросишь, то не будет. Соответствующие проверки в коде libswscale есть.

>тогда становится не очень понятно - почему libjxl встренные в ffmpeg не может без потерь jpg трогать, если у кодера есть доступ к сырым данным с декодера
Здесь тоже вопрос не понимаю.
Аноним (Microsoft Windows 10: Palemoon) 13/09/22 Втр 18:29:04 3205609 8
>>3205595
> Здесь тоже вопрос не понимаю
Это скорее не вопрос, а мысли в слух, никто не может взять в толк почему libjxl входящий в состав ffmpeg не может пережимать jpeg без потерь, как это делает другая реализация энкодера этого формата, а занимается преобразованиями, которые приводят к искажениям. В то время как для libx264, входящий в тот же ffmpeg позволительно сразу работать с yuv
В общем не бери в голову.
Аноним (Microsoft Windows 10: Firefox based) 13/09/22 Втр 19:08:38 3205627 9
изображение.png 40Кб, 577x594
577x594
>>3205595
>Даже самые современные x86_64 работают с целыми разика в полтора быстрее
Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Причём там же инструкция есть для сложения-умножения для плавающих на 32 и 64, а для целых я такой не вижу.

>Здесь тоже вопрос не понимаю.
Почему libjxl поддерживает перекодирование из jpg без потерь только вне ffmpeg?
Аноним (Google Android: Mobile Safari) 13/09/22 Втр 21:00:40 3205717 10
>>3205627
>Покажешь код (или скажи какой написать), в котором целые складываются-умножается быстрее дробных?
Знаешь, ты меня заинтриговал. Я погуглил. Оказалось, что моë мнение ошибочно.
https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware
Посоны утверждают, что в зависимости от длины чисел и конкретного камня получается по-разному. Если тебе есть, что сказать, то я бы с удовольствием послушал подробности. По остальным тезисам замечания есть?
Аноним (Microsoft Windows 10: Palemoon) 13/09/22 Втр 21:07:32 3205718 11
>>3205717
Я может слепой, но там начиная с хасвеллов инты считаются быстрее, что короткие, что длинные, если это инты, конечно.
Аноним (Microsoft Windows 10: Palemoon) 13/09/22 Втр 21:08:50 3205719 12
>>3205718
Кроме деления, но речь про сложение-умножение
Аноним (Microsoft Windows 10: Chromium based) 13/09/22 Втр 22:11:35 3205730 13
>>3205384 (OP)
Сжатие медиа - это, конечно, хорошо. Но как на счёт сжатия документов и программ?
Отдаю предпочтение 7-zip с кодеком lzma2 на максимальных настройках. Кто-то скажет, что мейнстрим, но выбирать не из чего. Альтернативы - мутная незадокументированная чепуха, без комьюнити и без бинарников. Которая, к тому же, не может сжимать несколько файлов и папки - то есть сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь в модный архивный кодек. А иногда и выигрыша в степени сжатия нет.
Аноним (Microsoft Windows 10: Firefox based) 13/09/22 Втр 22:15:47 3205731 14
>>3205717
Я просто тестил, и операции умножения-сложения на моём ноуте (да и не только на нём, до чего дотянулся) быстрее для float32, чем для целых чисел. Даже без simd.
Медленнее, только если упирается в скорость памяти, и условно говоря целые числа влезают в кеш, а флоаты - нет.

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

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

>>3205730
Можешь диск в оперативке сделать, и тар на нём размешать.
>Но как на счёт сжатия документов и программ?
Всё плохо, сжимать с потерями нельзя, потому хотя бы немного неупорядочненную информацию сжать нельзя. Программы не сжимаются, документы, только если формат текстовый, в противном случае едва ли даже 20% получишь. А если там хоть одна картинка в документе, то смысл теряется.
Аноним (Microsoft Windows 10: New Opera) 13/09/22 Втр 23:34:42 3205743 15
Всегда казалось что ffmpeg это какая-то сложная фигня, которую я никогда не осилю, а вот сегодня таки попробовал поделать вебмок, и на удивление всё оказалось легко и просто.
Кстати, в ffmpeg можно монтировать видосы как в Адоб премьере, или такая себе затея?
Аноним (Microsoft Windows 10: Palemoon) 14/09/22 Срд 00:36:34 3205754 16
photo2022-04-13[...].jpg 162Кб, 1062x1080
1062x1080
>>3205743
>можно монтировать видосы
Разрешаю.
> такая себе затея
Это.
Аноним (Linux: Firefox based) 14/09/22 Срд 06:52:59 3205793 17
>>3205743
Ну, она сложная, если ты, как пердолики сверху, будешь ебаться с битностью, хуитностью и прочими параметрами, которые нам, простым домозяйкам, непонятны. А на базовом уровне это обычная консольная утилита - скормил аргументы в нужном порядке и получил профит. Изи ту лёрн, хард ту мастер.
Аноним (Linux: Firefox based) 14/09/22 Срд 09:54:09 3205836 18
>>3205730
> сначала ты сжимаешь их в tar, мучаешь диск (при условии, что найдётся свободное место), и только потом сжимаешь
И упаковываешь их в tar. И теребишь им bzip2.
А что, перенаправление ввода-вывода отменили уже?

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

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

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

>>3205743
> ffmpeg это какая-то сложная фигня
Так-то, да. Я её исходники читаю с большим трудом. И не потому, что они написаны плохо. Примерно соглашусь с >>3205793.

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

> или такая себе затея?
Очень-очень такая себе. Если есть желание автоматизировать, то есть vapoursynth — нелинейный видеоредактор питоном (в смысле, что он построен как фреймсервер с питоновыми биндами и опускаемой обвязкой — можно сразу на упрощённом питоне писать редактирующий видео сценарий).
Аноним (Microsoft Windows 10: Chromium based) 14/09/22 Срд 10:07:49 3205838 19
Аноним (Google Android: Mobile Safari) 14/09/22 Срд 11:34:38 3205860 20
>>3205836
>целые и дробные числа числодробят у Штеуда разные
Так и у амд разные, alu и fpu, вопрос в количестве портов, на хасвелле их стало 4, которые могут в алу(некоторые вроде вообще кроме алу и сдвига больше ничего не делают), в интернетах есть блоксхема примерного состава этих портов, в тайгерлейке портов стало 5 и расширены в очередной раз их возможности, вплоть до авх инструкций.
Но возможно изменена и логика работы этих блоков вычислений, за неё я не знаю.
Аноним (Linux: Firefox based) 14/09/22 Срд 13:30:55 3205886 21
>>3205860
Я именно про это и говорю. Не стал использовать вводную конструкцию «в смысле», чтобы явно обозначить объект и предмет. Я не очень хорошо изъясняюсь — и прошу прощения за это.
Аноним (Google Android: Mobile Safari) 14/09/22 Срд 14:08:38 3205904 22
>>3205886
Я лишь уточнил, что логику могли не менять, а скорости могли повысить за счёт увеличения количества портов обработки целочисленной арифметики, потому как прирост на хасвелле и порты там добавили. Х
Это проще, чем блок операционный переделать, хотя в каком то пне что ли целочисленнные операции вообще с ошибкой выполнялись, так что переделывают и их.
Аноним (Google Android: Firefox based) 14/09/22 Срд 14:35:55 3205926 23
image.png 1038Кб, 1600x1000
1600x1000
Исходник: png
Lossy: avif или jpeg xl?
Lossless: avif или jpeg xl?
Аноним (Google Android: Firefox based) 14/09/22 Срд 14:36:42 3205927 24
Что лучше?
Аноним (Linux: Firefox based) 14/09/22 Срд 15:46:02 3205946 25
>>3205926
Что за херня? У тебя два разных кадра пережатых в хламину. Как это можно сравнивать?
Аноним (Google Android: Firefox based) 14/09/22 Срд 16:08:38 3205954 26
>>3205946
Не, это просто пик, лол. Я в треде мнения спрашиваю, допустим, у меня есть пикчи в png, что мне лучше для lossy из этих двух и что мне лучше для lossless из этих двух. Webp сразу нахуй.
Аноним (Linux: Firefox based) 14/09/22 Срд 18:02:50 3205994 27
>>3205954
Ты спрашиваешь что тебе делать с этим куском шакального пережатка пересохранённого в PNG? Удалить насовсем. Или сжать в JPEG/WEBP/HEIC/AVIF по самые помидоры, что-бы артефакты на артефактах полезли.
Аноним (Linux: Firefox based) 14/09/22 Срд 18:12:08 3206001 28
>>3205954
А если у тебя есть колекция lossless пикч которые тебе нужно пережать, то у тебя выбор из двух кодеков: AVIF и JPEG XL.

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

Выбирай AVIF если тебе нужен умный кодер, который будет кодировать 5 минут твои 16 мегапикселей, но перераспределит биты так что-бы резкие детали выглядел резче, а мыльные замылились ещё больше.
Аноним (Microsoft Windows 10: Palemoon) 14/09/22 Срд 18:12:08 3206002 29
>>3205994
Я думаю он всё-таки спрашивает, чем ему его коллекцию гей-порно в картниках пережать для архивации в джизипе.
Хейт в сторону лосслесс вебп вообще не вкурил.
Аноним (Google Android: Mobile Safari) 16/09/22 Птн 05:41:57 3206615 30
Почему, если на двач загружаешь vp8/9, вложенное в mp4, то по ссылке оно все равно переименовывается как webm? Там не V_VP9, а vp09. С av1 тоже самое, av01 по ссылке открывается с .webm
Аноним (Google Android: Mobile Safari) 16/09/22 Птн 05:50:55 3206616 31
К слову, hevc работает в хром, мысли?
Аноним (Google Android: Firefox based) 16/09/22 Птн 11:59:46 3206677 32
Чё там с вебп2?
Аноним (Microsoft Windows 10: Chromium based) 16/09/22 Птн 12:37:03 3206688 33
Аноним (Microsoft Windows 10: Firefox based) 20/09/22 Втр 14:44:59 3208229 34
изображение.png 18Кб, 1014x125
1014x125
изображение.png 13Кб, 1013x81
1013x81
Двачик, что мне делать с 10-и битным видео? Как перекодировать в 264-й, чтобы сохранить качество?
И с каких пор ффмпег перестал показывать отдельный битрейт для каждого потока, а показывает только общий?
Аноним (Linux: Firefox based) 20/09/22 Втр 15:29:41 3208248 35
>>3208229
Ты ебанулся, BDRip транскодить?
Аноним (Microsoft Windows 10: Firefox based) 20/09/22 Втр 16:08:51 3208257 36
>>3208248
Мой плеер не поддерживает 10 бит формат. Объясни, в чем я не прав.
Аноним (Microsoft Windows 10: Chromium based) 20/09/22 Втр 16:19:34 3208259 37
>>3208257
В том, что пользуешься этим плеером.
Аноним (Linux: Firefox based) 20/09/22 Втр 16:24:57 3208261 38
>>3208257
> качать 10-bit рипы в H264
У тебя для этого H265 есть. H264 должен быть 8-bit, и точка.
Аноним (Microsoft Windows 10: Chromium based) 20/09/22 Втр 17:48:41 3208277 39
>>3208261
>H264 должен быть 8-bit, и точка.
Ты скозал?
Аноним (Microsoft Windows 10: Firefox based) 20/09/22 Втр 18:52:31 3208298 40
>>3208259
Не по существу ответ.

>>3208261
Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.
Аноним (Microsoft Windows 10: Chromium based) 20/09/22 Втр 20:05:10 3208325 41
>>3208298
>Че? У меня релиз 265@10 бит, нужно сделоть 264@8 бит. Я спрашиваю как это сделать, вы городите чушь.
Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
Аноним (Linux: Firefox based) 20/09/22 Втр 21:47:15 3208390 42
>>3208325
Да не в инет, у него плеер древний. H264 поддерживает, а H265 уже нет.
Аноним (Microsoft Windows 10: Chromium based) 20/09/22 Втр 22:23:23 3208405 43
>>3208390
>у него плеер древний
Врятли это причина. Пускай h264 рип качает тогда.
Аноним (Linux: Firefox based) 20/09/22 Втр 22:37:27 3208419 44
>>3208405
Так это и есть H264, но неправильный, 10-битный. Почему он сам не додумался скачать нормальный рип или ремукс, ума не приложу.
Аноним (Microsoft Windows 10: Palemoon) 21/09/22 Срд 00:13:39 3208453 45
16498481847760.jpg 109Кб, 1080x1080
1080x1080
Почему он просто не посмотрел в интернете
Аноним (Google Android: Mobile Safari) 21/09/22 Срд 05:31:04 3208517 46
>>3208229
ffmpeg -c:v libx264 -pix_fmt yuv420p
Аноним (Microsoft Windows 10: Firefox based) 21/09/22 Срд 10:54:48 3208560 47
>>3208419
>не додумался
Потому что я еблан и я это признаю. На своем же скриншоте >>3208229 не разглядел h264, охуеть я баран. Но от моего самобичевания лучше не станет, поэтому к теме.
Все дело в том, что я положил кучу сил на сборку конкретно этого релиза, но по какой-то странной причине не обратил внимания на битность видео, ебать релизеров в сраку. Я своими руками собирал дорожки с озвучкой и клеил их, а в итоге обнаружил, что встроенный в 11-е окна плеер не может его показать и я не сразу понял, что к чему. Да, забыл сказать для чего это все. Я никуда не выкладываю, просто хотел в коллекцию, то есть длясибя.
Короче что проще - скачать нормальный рип и заново приклеить озвучки или все же можно перекодировать видео в уже готовом контейнере?

>>3208517
Храни тебя бог анон, но я вот уже сам начал сомневаться, что пережимать рип норм затея.
Аноним (Linux: Firefox based) 21/09/22 Срд 12:17:30 3208578 48
>>3208560
Смотри, у тебя есть 2 пути, и оба ведут к торрент-трекеру.

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

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

Если имеешь дело с WEB, пережатие скорее всего не требуеться, убедись только что у тебя формат видеодорожки H264 8bit а не H265 10bit HDR DolbyVision.
Аноним (Microsoft Windows 10: Firefox based) 21/09/22 Срд 18:29:21 3208639 49
>>3208578
То есть вариант с еблей мы даже не рассматриваем, окей. Ладно, я все понял. Есть еще вопрос: зачем и нахуя люди пилят 10 бит видео? Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой. У меня пиздатый моник, не хдр конечно и не 10 бит, но у большинства людей с торрентов тоже не одиссей джи 9 или че там щас в тренде. И что сука характерно, пилят 10 бит в основном для аниме. ЗАЧЕМ?
Аноним (Microsoft Windows 10: Palemoon) 21/09/22 Срд 18:36:37 3208640 50
16525926709290.png 526Кб, 740x677
740x677
>>3208639
> То есть вариант с еблей мы даже не рассматриваем
Второй вариант это и есть вариант с еблей, где ты берёшь исходник лучшего какчества и уродуешь. Не рассматривается вариант пожатия пожатого.
Аноним (Microsoft Windows 10: Chromium based) 21/09/22 Срд 18:45:24 3208644 51
>>3208639
Цвета лучше, сжатие лучше. Дебандинг.
Аноним (Linux: Firefox based) 21/09/22 Срд 19:15:48 3208649 52
16632559322870s.jpg 8Кб, 250x250
250x250
>>3208560
> скочал нормальный 10-ти битный рип
> гавна встроенная в гавну не поддерживает нормальный 10-ти битный рип
> надо угандошивать нормальный 10-ти битный рип пережатием в менее сжимаемый 8-ми битный чтобы гавна встроенная в гавну поддерживала
Аноним (Linux: Firefox based) 21/09/22 Срд 19:23:24 3208652 53
>>3208639
> Я видел картинки с сравнением типа градиенты с 10 бит мягче, но если честно разницы вообще нет никакой.
Разница есть. С 8-бит в темных сценах аниме ебаные круги бандинга.
И в hi10p не тратится битрейт на борьбу с этим бандингом или чем-то другим, так что энкодер может либо сделать поменьше вес видео, либо улучшить качество с тем же весом.

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

Видели шутки, которые не шутки, про то что порно индустрия много раз первой осваивала и распространяла новую технологию? Вот с аниме по сути похожая ситуация тогда произошла.
Как сейчас не знаю. Кто-то энкодит пиратство в h.265 или AV1?
Аноним (Microsoft Windows 10: Palemoon) 21/09/22 Срд 19:34:03 3208656 54
>>3208652
> Кто-то энкодит пиратство в h.265 или AV1
Анимешники и энкодят, даже тестировали fate'вым касанием небес процессорный декод av1 в райзентреде.
Аноним (Microsoft Windows 10: Firefox based) 21/09/22 Срд 20:27:59 3208666 55
>>3208640
>и уродуешь
Ну зачем ты так..

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

>>3208649
Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв. Как ты узнал?
Аноним (Linux: Firefox based) 21/09/22 Срд 21:20:16 3208679 56
>>3208666
> Да, я не сижу на ляликсе и у меня волосы встают дыбом от мысли, что нужно будет руками трогать мпв.
То есть кроме стокового и MPV ничего нет? А как же MPC, тот же "потный даун", ну или VLC в конце концов? Мне казалось что этих плееров у вас там хоть жопой жуй, и выбирать можно по симпатичности GUI и нескучным обоям.
Аноним (Google Android: Mobile Safari) 22/09/22 Чтв 18:02:41 3208829 57
сап сосака
Хочу перекодировать видео в вебм, но 1. чтоб видео, которые разрешением больше указанного, сжимались в габаритах, 2. чтоб они не растягивались.

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

Как делать?
Аноним (Microsoft Windows 10: Palemoon) 22/09/22 Чтв 18:38:22 3208839 58
Diona-(Genshin-[...].jpeg 34Кб, 405x764
405x764
Аноним (Microsoft Windows 10: Chromium based) 22/09/22 Чтв 19:42:16 3208851 59
>>3208829
Делением как еще. Ссылку уже кинули, но почему-то через россии заблочили, пидоры. С впн открывает.
Аноним (Microsoft Windows 10: Firefox based) 22/09/22 Чтв 20:20:32 3208856 60
>>3205384 (OP)
Моя команда для кодирование в av1 из прошлого треда. Как вам?

echo -- -- -- && time /t && echo -- -- -- && ffmpeg -i "sourcefile.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svt1av1\outfile.ivf" && ffmpeg -i "sourcefile.mkv" -map 0:a:0 -b:a 172k -c:a libopus -filter:a "aresample=48000:resampler=soxr:precision=33" "!svt1av1\outfile.opus" && ffmpeg -i "!svt1av1\outfile.ivf" -i "!svt1av1\outfile.opus" -vcodec copy -acodec copy "!svt1av1\outfile (svtav1).mkv" && echo ~~ ~~ ~~ && time /t && echo ~~ ~~ ~~

Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
--keyint 1s - очень люблю перемотку на 1-2 секунды и очень не люблю точный (медленный) поиск. Увеличивает размер файла, но не сильно.
--preset 5 - на шестом пресете жопа по качеству, на четвёртом состариться успеешь.
--crf 19 - жирно, но иначе качество ощутимо портится, 19 в самый раз. Компенсация пятого пресета.
--tune 0 - VQ (visual quality) режим, выглядит многократно лучше дефолтного PSNR (объективные математические показатели). Ума не приложу, почему не стоит по дефолту. На реддите писали о повышенной резкости, я такого не заметил.
--film-grain 8 - многие фильмы и аниме имеют шум (зерно, grain), эта опция им нужна.
yuv420p10le выбрал по гайду из шапки. Пишут, будет лучше сжатие и лучше качество.
-strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
opus выбрал за лучшую спектрограмму относительно aac >>3202282 →. Так же для опуса я нашёл значительно больше статей и тестов прослушивания, с ним не нужно заморачиваться, выбирая кодировщик и собирая ffmpeg подсибя с поддержкой fdk-aac, свободная лицензия. На хабре автор статьи писал, что порогом прозрачности у опуса для него оказался битрейт около 170, я выбрал 172 с запасом. -filter:a использую по привычке - помню, некоторое время назад, кодировал без этого ресемплера, и громкость в опусе сильно снизилась.

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

Такая команда сжимает 25-минутные аниме до 380-620 Мб (5117 Мб на 10 видео) за 120-130 минут на моём железе. В другом тайтле одна серия весит уже 500-1000 Мб, но это, полагаю, из-за более сильного шума, который к тому же двигается. Избыточная информация как-никак. Но повышение --film-grain до 16 особого результата не дало (или качество ухудшилось. короче, отказался я от этой идеи, остался восьмёрке).
Аноним (Microsoft Windows 7: Firefox based) 23/09/22 Птн 03:18:56 3208891 61
>>3208856
> дополнительный аудиодорожки проебываются
> встроенные сабы проебываются
> метаинфо проебывается
> ненужно1кодек
говно/10
Аноним (Google Android: Mobile Safari) 23/09/22 Птн 04:20:44 3208894 62
>>3208856
> Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
Нихуя подобного
> -strict -1 определяет уровень совместимости-новизны стандартов, но зачем здесь нужен - хз. Скопировал с интернета, пояснений не нашёл.
Не нужно давно, это для ффмпег раньше только
Аноним (Linux: Firefox based) 23/09/22 Птн 06:42:06 3208899 63
Аноним (Microsoft Windows 10: Chromium based) 23/09/22 Птн 17:34:45 3209059 64
>>3208856
>Выбрал SvtAv1EncApp вместо встроенного в ffmpeg, так как только в нём можно выставить --keyint в секундах.
В чем проблема выставить не в секундах?
>Нихуя подобного
Вообще-то он прав. Выставить в секундах можно в av1enc. В ffmpeg ставить только по старому, значением.
Аноним (Microsoft Windows 10: Firefox based) 23/09/22 Птн 18:37:59 3209074 65
>>3208891
>> дополнительный аудиодорожки проебываются
Озвучки мне не нужны, но они обычно отдельным файлом лежат. Комментарии от создателей на японском мне тоже не нужны. Остаются дорожки в 5.1 или стерео варианте, какая лучше звучит - ту и выбираю. Всё это время выбирал стерео (в тех релизах другой не было).

>> встроенные сабы проебываются
Делаю их внешними дополнительной командой. Внешние лучше по факту.

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

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

>>3208894
>Нихуя подобного
В документации к 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]
Вообще, отдельный энкодер лучше комбайна, как минимум в теории.

>>3209059
>В чем проблема выставить не в секундах?
Не знаю. Когда читал, забыл видимо, что в секунде всегда одинаковое количество кадров.
Аноним (Microsoft Windows 7: Firefox based) 23/09/22 Птн 19:03:44 3209088 66
>>3209074
> Сжимает лучше x265, разве нет?
Нет? позиционировался и продолжает как улучшение x264. Да, лучше чем x264. x265 - нет, в лучшем случае на уровне. И уж точно в разы медленней и ресурсоемче.

>
Чего тогда рейт реквестируешь если сугубо для твоих хотелок и задач однострочник?
Аноним (Microsoft Windows 10: Chromium based) 23/09/22 Птн 19:14:19 3209094 67
>>3209074
>Вообще, отдельный энкодер лучше комбайна, как минимум в теории.
По сути не лучше, потому что в ffmpeg есть встроенные плюшки по типу фильтров, скэйлингов и прочего. А параметры самого энкодера легко вписываются в -svtav1-params.
Аноним (Linux: Firefox based) 23/09/22 Птн 19:22:35 3209100 68
>>3209088
> Нет? позиционировался и продолжает как улучшение x264.
Ты имел в виду VP9?
Ну так-то он чуть лучше HEVC, но ты попробуй заведи HEVC в хроме или фуррифоксе.
Аноним (Google Android: Mobile Safari) 23/09/22 Птн 19:30:31 3209102 69
>>3209074
Ичо что там сказано, есть параметр --svt-params keyint:10s вроде в прошлый раз работало. Пайпинг это полнейшая хуйня всегда
Аноним (Microsoft Windows 10: Chromium based) 23/09/22 Птн 19:37:18 3209104 70
>>3209100
>Ну так-то он чуть лучше HEVC
Cфигали?
Аноним (Linux: Firefox based) 23/09/22 Птн 19:57:41 3209113 71
>>3209104
Ну в смысле не VP9 а AV1.

А VP9 да, это конкурент H264, с вразы более медленным временем кодирования чем x264, ненужный нигде кроме кодирования на low-end битрейтах.
Аноним (Microsoft Windows 10: Firefox based) 23/09/22 Птн 20:11:04 3209120 72
>>3209104
По факту же, если скорость кодирования не учитывать.
Даже дефолтный средний vp9 самый тяжелый hevc вроде как обгоняет...
Аноним (Linux: Firefox based) 23/09/22 Птн 20:18:03 3209124 73
>>3209120
Сравнивать надо не --cpu-used 6 с --preset placebo, а качество изображения, полученное за одинаковое время кадра.
Аноним (Microsoft Windows 10: Firefox based) 23/09/22 Птн 20:22:11 3209126 74
>>3209102
>Пайпинг это полнейшая хуйня всегда
Почему? Неудобно может быть, согласен - команды длинные. И если команду нужно встроить куда-то, то вообще не вариант.
Аноним (Microsoft Windows 10: Firefox based) 23/09/22 Птн 20:40:22 3209132 75
>>3209124
> полученное за одинаковое время
Тогда победит h264 и svt, если время малое, и что-то потяжелея, если время больше.
Аноним (Microsoft Windows 10: Chromium based) 23/09/22 Птн 20:43:57 3209133 76
>>3208560
>встроенный в 11-е окна плеер
Нахуй идет, ставишь кодек лайт (внутри MPC) или Potplayer
Аноним (Microsoft Windows 10: Firefox based) 23/09/22 Птн 22:56:53 3209158 77
>>3209133
>кодек лайт (внутри MPC) или Potplayer
Нахуй идет, ставишь mpv.
Аноним (Google Android: Mobile Safari) 24/09/22 Суб 00:42:20 3209170 78
>>3209126
Медленно, требует копирования огромного количества данных из одного процесса в другой, сжирает кучу оперативки, при ошибке ложатся оба процесса
Аноним (Google Android: Mobile Safari) 24/09/22 Суб 00:43:21 3209171 79
svt-av1 vs x265 Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 11:06:20 3209233 80
Кодировал один и тот же исходник хорошего качества в svt-av1, а затем в x265. Окончания x265 так и не дождался, завершил на 61 секунде из 1401 всего видео.

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

Команда для svt-av1:
ffmpeg -i "EP01.mkv" -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 5 --keyint 1s --crf 19 --film-grain 8 --tune 0 -b "!svtav1\EP01.ivf"

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

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

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

Вердикт: svt-av1 лучше по качеству, сжимает быстрее и сильнее, чем x265.
Аноним (Microsoft Windows 10: Chromium based) 24/09/22 Суб 11:39:22 3209238 81
>>3209233
вердикт говно, потому что надо кодировать одинаковую длительность.
Аноним (Microsoft Windows 7: Firefox based) 24/09/22 Суб 11:43:00 3209239 82
>>3209233
> SVT-AV1
Теперь покажи это свое квадратомыльце.
Аноним (Microsoft Windows 7: Firefox based) 24/09/22 Суб 12:14:06 3209246 83
>>3209239
Хмм, беру свои слова назад. Неплохо поработали над ним в последних версиях ffmpeg'а.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 13:15:16 3209257 84
x265.png 7896Кб, 3840x2160
3840x2160
svtav1.png 9290Кб, 3840x2160
3840x2160
>>3209238
Согласен, коллега. Провёл эксперимент заново, закодировал два равных по длине отрезка (-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"


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

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

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

Заметил ещё одну очень странную вещь - если указать x265 "keyint=24", то вес файла уменьшится. Без этой опции 131 868 Кб, и ключевые кадры расставлены раз в 12 секунд по моим наблюдениям. Хотя должно быть ровно наоборот - больше ключевых кадров = больше вес файла.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 13:16:54 3209259 85
source.png 10420Кб, 3840x2160
3840x2160
>>3209257
И скриншот оригинала, который я не успел добавить к первому сообщению, потому-что капча обновлялась быстрее, чем я загружал.
Аноним (Google Android: Mobile Safari) 24/09/22 Суб 13:40:48 3209261 86
>>3209233
Сука, не надо использовать пресет slower. Slow наиболее оптимальный.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 14:53:55 3209269 87
>>3209261
av1 сжимает в несколько раз эффективнее, ещё и шум убирает, так что x265 не надо использовать вообще.
Аноним (Microsoft Windows 10: Chromium based) 24/09/22 Суб 14:57:52 3209270 88
>>3209257
av1 видно мылит, детали теряются.
Аноним (Microsoft Windows 10: Chromium based) 24/09/22 Суб 14:59:48 3209272 89
>>3209269
ты ведь пыняешь, что crf 19 в x265 и av1 не одно и тоже. Кодировать надо с одинаковым битрейтом.
Аноним (Microsoft Windows 10: Palemoon) 24/09/22 Суб 15:44:11 3209283 90
image.png 1250Кб, 1280x767
1280x767
>>3209269
> mfw мыльцонство шума выставляется как что-то хорошее
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 17:12:43 3209305 91
>>3209270
Да, посмотрел на другую часть картинки и заметил.
Как же тогда сжимать видео, чтобы без потери деталей?
Аноним (Linux: Firefox based) 24/09/22 Суб 18:26:27 3209337 92
>>3209305
x264 на 10 мегабит и не мучайся.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 18:41:43 3209339 93
>>3209337
Толсто. Такой транскод только увеличит размер файлов.
Аноним (Linux: Firefox based) 24/09/22 Суб 19:26:11 3209344 94
>>3209339
Отлично. Значит ничего пережимать и не надо. Оставляй оригинал как есть.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 19:28:35 3209345 95
>>3209344
Зачем тогда этот тред нужен, если здесь предлагают "оставить как есть" и "раздуть до 10 мбит/с"?
Аноним (Microsoft Windows 10: Chromium based) 24/09/22 Суб 19:39:15 3209347 96
1530823796245.webm 20299Кб, 320x180, 02:07:23
320x180
>>3209345
Это залётыши. Тру юзеры ффмпега смотрят фильмы только так.
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 19:52:24 3209353 97
>>3209347
Шакал Квадратович, добро пожаловать!
Аноним (Microsoft Windows 10: Firefox based) 24/09/22 Суб 21:17:06 3209386 98
>>3209347
А может кто-то загрузить и через svt такое сделать на 20 мб, для теста?
У меня просто мобилка, 200 кбит/с.
Аноним (Linux: Firefox based) 24/09/22 Суб 22:06:24 3209405 99
Есть ли толк перегонять AVC в HEVC ради уменьшения размера (с допустимой незначительной потерей качества)? Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
Аноним (Microsoft Windows 7: Firefox based) 24/09/22 Суб 22:32:51 3209416 100
>>3209257
>>3209259
Чет дофига "додумало" в av1. Это как с говнофильтрами "улучшаторами" смотреть. Ну такое.
Тут более-менее смотрится, полно однотонных участков. А на динамичных и прегруженых деталями (листва) сценах изрядная дрисня вероятно будет получаться.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 00:46:58 3209434 101
>>3209416
>изрядная дрисня вероятно будет получаться
Вероятно. По идее от битрейта зависит, а битрейт динамически выставляется crf - чем загруженнее сцена, тем больше на неё битрейт.
Надеюсь, что всё-таки проблема тех скриншотов из-за чрезмерного шума, и в современных тайтлах, где шума нет, или незначительно мало, svtav1 будет кодировать намного лучше. За сегодняшний день я изрядно огорчился в способностях кодеков, думал, сожму раз эдак в 6 без видимых глазу потерь, но нет. Хотя с предыдущим тайтлом получилось сжать без видимых потерь, или может я слишком мало сцен там сравнивал.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 00:52:31 3209436 102
n2-svtav1.png 14210Кб, 3840x2160
3840x2160
n2-source.png 15069Кб, 3840x2160
3840x2160
>>3209434
>>3209416
Вашему вниманию скриншоты того самого тайтла с меньшим шумом.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 01:12:58 3209443 103
>>3205384 (OP)
> ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
О каком "баттле" может идти речь, если VVC не поддерживается в mpv, только в васянской сборке https://github.com/MartinEesmaa/VVCEasy ? В других плеерах тоже не поддерживается, только через мокрописи-дополнения. И в ffmpeg его нет. Хуйня сырая в общем, ждём.
Аноним (Microsoft Windows 7: Firefox based) 25/09/22 Вск 01:35:49 3209447 104
>>3209436
Как на счет каких-нибудь ИРЛ видосикв с кустиками? Есь чо? Или кинца хоть. Лень качать.
Аноним (Linux: Firefox based) 25/09/22 Вск 04:02:49 3209462 105
>>3209386
Твоя мобила AV1 не потянет. Только 3GPP в 144p с квадратами на весь экран.
Аноним (Linux: Firefox based) 25/09/22 Вск 04:16:11 3209463 106
>>3209405
> Или это беспонтовая затея уровня "конвертировать из lossy MP3 в другой lossy-формат"?
Именно.
>>3209345
Какой вопрос — такой ответ. Хотите visually lossless — соблюдайте заветы торентоблядей. x264, пердолинг с параметрами на уровне пресета placebo и битрейты как половина от блюрея ждут вас.

Хотите сжатия? Минимального размера при максимальной эффективности? Тогда выбирайте подходящий для вас CRF, устраивающий вас пресет или --cpu-used, и вперёд. И не надо ни у кого спрашивать, какой CRF лучше. Сам сравни и выбери наилучший для тебя.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 04:18:06 3209464 107
>>3209462
Я не смотрю видео с мобилы.
Аноним (Google Android: Mobile Safari) 25/09/22 Вск 07:40:07 3209475 108
Опять болезные пытаются svt-av1 сравнивать с какой-то хуйней, когда в прошлом тренде уже доказали, что при одинаковом времени кодирования svt-av1 сосёт хуй у aom.
Аноним (Microsoft Windows 7: Firefox based) 25/09/22 Вск 07:56:59 3209477 109
aom.png 1Кб, 768x16
768x16
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 08:31:12 3209480 110
image.png 4Кб, 931x17
931x17
Опять криворукие дурачки, не сумевшие в пресеты, вылезли.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 10:51:18 3209492 111
trac.ffmpeg.org перестал открываться.
Аноним (Linux: Firefox based) 25/09/22 Вск 10:53:21 3209493 112
>>3209480
Пресеты с цифрой больше чем 4 не нужны.
Аноним (Google Android: Mobile Safari) 25/09/22 Вск 11:11:52 3209499 113
>>3209480
Ох уж этот пресет у долбоеба который выглядит хуже x264 slow
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 11:38:52 3209501 114
>>3209493
>>3209499
Пресет 8 в aom выглядит неотличимо от пресета 5 в svt-av1, но svt-av1 кодирует в два раза дольше, чмоньки.
Аноним (Linux: Firefox based) 25/09/22 Вск 12:13:55 3209509 115
>>3209501
Откуда инфа? Тоже хочу посмотреть.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 12:26:37 3209512 116
>>3209509
Инфа из прошлого треда.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 12:39:14 3209513 117
>>3209501
>Пресет 8 в aom
У aom есть пресеты? А что ещё у него есть? Хочу увидеть документацию по всем параметрам.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 12:53:38 3209515 118
image-79005-2.jpg 163Кб, 1280x1155
1280x1155
Перепробовал многие кодеки, и пришёл к выводу, что единственный хороший из них - пикрилейтед. В конце своих скитаний и напрасно потраченного времени вы это поймёте.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 12:55:19 3209516 119
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 12:58:07 3209517 120
>>3209516
Ну и где там "preset"? Поиск на странице дал 0 результатов, нет там этого слова.

>ffmpeg.org
Не открывается.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 13:02:28 3209519 121
1664100147209.png 521Кб, 1200x600
1200x600
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 13:09:04 3209520 122
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 13:12:42 3209521 123
1664100761799.png 521Кб, 1200x600
1200x600
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 13:13:23 3209522 124
Аноним (Linux: Chromium based) 25/09/22 Вск 13:24:40 3209524 125
как ускорить кучу мп3-файлов в 2 раза чтобы они не начали пищать как будто гелия надышались?
Аноним (Linux: Firefox based) 25/09/22 Вск 13:48:35 3209529 126
>>3209520
cpu-used в aomenc
preset в svt-av1

Что непонятного?
Аноним (Microsoft Windows 7: Firefox based) 25/09/22 Вск 14:06:27 3209536 127
>>3209515
Хороший кодек. Но я бы предпочитаю кодек WD.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 14:56:55 3209548 128
>>3209515
А как таким кодеком шебмы на 2ch.hk заливать?
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 16:17:48 3209575 129
>>3209524
обычный спидап, чем еще. -filter:a "atempo=2.0"
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 16:54:14 3209581 130
1664114049618.png 5352Кб, 3840x2160
3840x2160
1664114049630.png 4469Кб, 3840x2160
3840x2160
1664114049637.png 5703Кб, 3840x2160
3840x2160
1664114049652.png 2831Кб, 3840x2160
3840x2160
Ну что же, давайте подумаем, где какой кодек, и какой из них лучше. Слева сверху, очевидно, сурс. На пикчах одни и те же кодеки расположены одинаково, т.е. справа сверху всегда один и тот же кодек.
Варианты для угадывания:
libsvtav1 c -preset 4
libaom-av1 с -cpu-used 8
libsvtav1 c -preset 5

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

Сегодня в 22:00 по МСК скину пароль. Или завтра, смотря как получится.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 16:55:33 3209582 131
1664114127378.png 3934Кб, 3840x2160
3840x2160
1664114127388.mp4 20319Кб, 1920x1080, 00:03:19
1920x1080
>>3209581
И в качестве бонуса, вот еще сурс, пожатый x264 с пресетом плацебо.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 17:03:30 3209583 132
>>3209475
>что при одинаковом времени кодирования
При одинаковом времени кодирования aom не работает. Можешь показать при каких настройках aom сможет кодировать 1280х720х60 в реальном времени? Или хотя бы со скоростью 0.5?
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 17:11:16 3209584 133
16637861174630.jpg 452Кб, 1080x1642
1080x1642
>>3209581
>>3209581
> давайте подумаем
> libsvtav1 c -preset 4
> libaom-av1 с -cpu-used 8
> libsvtav1 c -preset 5
Чтобы что? Шебмы для двача кодируешь? Да можешь хоть в вп8 делать, а фильмоделы, борцуны за какчество, ждут vvc.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 17:18:02 3209585 134
>>3209583
Болезный, тебе зачем на процессоре av1 кодировать в реалтайме? Жди хардверных энкодеров на видеокартах, ими и кодируй с большими битрейтами, если до пизды нужно кодировать в ав1. А что же касается непосредственно вопроса, то aom не может кодировать в реалтайме. А то, что кодирует в реалтайме svt - мыло мыльнейшее.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 17:19:02 3209586 135
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 17:24:38 3209589 136
>>3209585
Меня не интересуют кодеры работающие со скоростью меньше 0.3.
Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.

>мыло мыльнейшее.
Всё ещё лучше реалтаймовых vp9/h264/h265 при том же битрейте.
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 17:26:40 3209590 137
>>3209581
>3
ты хочешь что у людей глаза к хуям вытекли. Пики говно. Нах на мыльном говниме сравнить, тем более без деталей,
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 17:29:12 3209592 138
>>3209590
>Нах на мыльном говниме сравнить, тем более без деталей
Критикуешь - предлагай.
Аноним (Linux: Chromium based) 25/09/22 Вск 17:48:35 3209599 139
1567824512303.webm 5791Кб, 480x480, 00:02:17
480x480
>>3209575
спасибо, теперь буду превращать дум-метал в танцевальную музыку.
Аноним (Linux: Firefox based) 25/09/22 Вск 17:53:15 3209603 140
>>3209581
Ну что, давайте присвоим этим секциям номер, слева-направо сверху-вниз

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

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

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

Кадр 4: бандинг, бандинг, бандинг. Везде бандинг кроме исходника. Скажи честно, ты его в 8 бит сжимал? Впрочем, даже если в 10, не удивлюсь. Но с этим бандингом надо бороться. Даже не знаю как это сделать не раздувая битрейт. Я даже сомневаюсь что 12 бит уберет бандинг. Может сгладит границы, и контуры цветовых переходов станут выглядеть аккуратнее, но вот как забороть бандинг насовсем не знаю.
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 18:13:17 3209610 141
>>3209443
> ждём официального исхода баттла VVC vs AV1
> Хуйня сырая в общем, ждём.
Там так и написано..
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 18:18:02 3209614 142
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 18:20:22 3209615 143
>>3209610
> исхода баттла VVC vs AV1
О каком баттле идёт речь? Как всегда, VVC aka H.266 займёт место на 8K HDR блуреях, а AV1 как свободный от патентов на YT/интернет видео. AV1 нужно скорее с H.265 сравнивать, который, к слову, уже внедрили в Сафари и в Хром. Спустя 10 лет может и выкатят кодек, который сопоставим с VVC, но сейчас мощи H.265 избыточны. AV1 как был свободным мыльцом так и останется, не в тот состоянии, чтобы с проприетарными кодеками тягаться.
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 18:23:07 3209616 144
>>3209592
Качественные футажи прогулки по траве.
мимо
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 18:24:55 3209617 145
Аноним (Linux: Firefox based) 25/09/22 Вск 18:34:01 3209619 146
>>3209589
> Я не гугл который кодирует 1 раз, и потом видос 1000000 смотрят. Я человек, который кодирует один раз, и потом смотрю 1-10 раз, может быть кому-то показываю ещё. Кодировать видео час, чтобы потом суммарно смотреть его меньше часа - это глупость какая-то.

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

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

Иначе говоря, если ты хочешь сохранить значительный объём информации на долгий срок, то транскодирование безусловно выгодно.
Например, у тебя есть 200 Гб видео, которое ты хочешь сохранить у себя навсегда. Допустим тебе придётся затратить месяц на транскодирование всех этих видео. Что выгоднее, транскодировать месяц и получить 100 Гб информации заместо 200 Гб, которые ты будешь хранить годами, или таскать с собой все 200 Гб переливая их с одного HDD на другой + регулярные бекапы на чёрный день?
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 18:36:22 3209621 147
>>3209619
При хранении личных видео на года тем более не хочется терять качество.
мимо
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 19:00:45 3209632 148
>>3209603
Ты ещё пятый кадр пропустил, он постом ниже.
>Скажи честно, ты его в 8 бит сжимал?
Да, все видео были сжаты в 8 бит, и на то, что я не пожал в 10 бит, есть несколько причин.

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

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

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

>>3209616
Увы, у меня таких футажей нет, откуда брать - не знаю, а сервисами со стоками я не пользуюсь.
Аноним (Linux: Chromium based) 25/09/22 Вск 19:03:30 3209634 149
если верить сайту амд моя видеокарта поддерживает аппаратное кодирование h265 https://www.amd.com/en/products/graphics/amd-radeon-rx-6600-xt но когда я пытаюсь кодировать получается зелёный экран и наверху какие-то ошмётки от видео. с чем это может быть связано?
Аноним (Microsoft Windows 10: Chromium based) 25/09/22 Вск 19:13:08 3209635 150
>>3209634
Это значи амуде говно.
Тут не эктрасенсы сидят, чтобы гадать как чем ты кодировал..
Аноним (Linux: Firefox based) 25/09/22 Вск 19:16:50 3209636 151
>>3209632
> Первая заключается в том, что я не очень уверен, что большинство браузеров и аппаратных кодеков умеют (будут уметь) декодировать 10 бит ав1.
Должны, ибо находятся в одном и том-же профиле — стандартном. Лишь для 12 бит нужно активировать high profile.

И как я уже сказал, с бандингом нужно бороться. И 10 битный режим значительно уменьшает бандинг. Это я про 12 бит сказал что он может и не устранить бандинг насовсем, но тут уже вопрос делает ли декодер RGB дизеринг.
Аноним (Linux: Firefox based) 25/09/22 Вск 21:44:14 3209653 152
>>3209632
>>3209582
Ну значит посмотрел я 5-й кадр. Тут мне 2-й сегмент понравился больше чем четвёртый почему-то. И да, только libaom попытался в чёткость, но получилось у него только то что можно было предсказать, всё остальное тоже мыльное. А у svt мыльное всё.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 22:02:25 3209656 153
>>3209581
Только один пока решился расписать что-то, видимо придется ждать до завтра.
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 22:59:20 3209662 154
>>3209610
Доколе ждать? Есть примерные сроки, когда выкатят стабильный кодировщик и видеоплееры обзаведутся нужным декодером?

>>3209615
По части звука так же - проприетарный aac лучше свободного opus?
Аноним (Microsoft Windows 10: Firefox based) 25/09/22 Вск 23:06:43 3209663 155
Аноним (Linux: Firefox based) 26/09/22 Пнд 00:08:54 3209667 156
>>3209663
Когда же декодер добавят в ffmpeg? Кодировать уже есть чем, а декодировать нечем.
Аноним (Google Android: Mobile Safari) 26/09/22 Пнд 07:37:13 3209697 157
>>3209615
> AV1 нужно скорее с H.265 сравнивать
Откуда такая информация?
Аноним (Google Android: Firefox based) 26/09/22 Пнд 09:36:21 3209712 158
>>3209663
А если меня не интересуют отчетливые голоса на битрейтах картошки, а интересует сохранность всех слышимых деталей до 20-22 кГц, какой мне кодек звука использовать?
Аноним (Google Android: Mobile Safari) 26/09/22 Пнд 09:50:48 3209714 159
Аноним (Google Android: Firefox based) 26/09/22 Пнд 10:37:59 3209719 160
>>3209714
Толсто. Прямо как вес wavpack файлов.
Аноним (Linux: Firefox based) 26/09/22 Пнд 11:36:43 3209730 161
>>3209712
Ну и зачем тебе этот кодек когда он ещё толком ничем не поддерживается?

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

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

У опуса я так понял до сих пор плохая совместимость? Что-то круче него не придумали еще?
Аноним (Linux: Firefox based) 26/09/22 Пнд 13:17:48 3209745 164
>>3209737
У AAC почти так-же. AAC не поддерживают только китайские MP3 плееры, китайские наушники с функцией mp3 плеера, ну и какой-нибудь музейный раритет. Даже старые кнопочные телефоны поддерживают AAC LC.

Opus открывается на любом более менее актуальном смартфоне. Если у тебя остался старый едва работающий смартфон на Android 4 и младше, то у тебя есть выбор между AAC и Vorbis.
Аноним (Google Android: Firefox based) 26/09/22 Пнд 13:18:07 3209747 165
>>3209737
>везде
В пизде.
Обзаведись портативным устройством под бюджет, софтовым плеером на вкус, и будет тебе настоящее везде. Mp3 по факту устарел, ему не место в 2022 году ни под каким соусом. Гоните и насмехайтесь над теми, кто в него сжимает. Не место, так же как и огрызкам, которые ничего современные не поддерживают.
Аноним (Google Android: Mobile Safari) 26/09/22 Пнд 19:21:57 3209847 166
>>3209719
Что ты высрал, клоун?
У этого кодека очень щадящее сжатие, как раз останутся все частоты
Аноним (Microsoft Windows 10: Firefox based) 26/09/22 Пнд 22:00:30 3209899 167
>>3209581
Пароль от архива: 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
Аноним (Microsoft Windows 10: Palemoon) 26/09/22 Пнд 22:20:19 3209902 168
16492558823400.png 278Кб, 640x578
640x578
Аноним (Microsoft Windows 10: Firefox based) 26/09/22 Пнд 22:25:11 3209903 169
>>3209899
А нахуя архив, если ты команды скинул?
Аноним (Linux: Firefox based) 26/09/22 Пнд 23:08:44 3209926 170
>>3209899
То есть я не угадал ни в одном из случаев.

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

Лучшим оказался svt1av1 с пресетом 4, что в общем то логично. Кстати, нужно сравнить svtav1 preset 4 с aomenc cpu-used 4 запущенным через av1an.
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 08:32:15 3209985 171
>>3209714
Чем он лучше опуса?
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 18:09:53 3210111 172
Я не пойму vvc вышел или нет, можно в него покодировать, какая производительность? Пока что компилирую и посмотрю что да как.
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 18:37:44 3210116 173
>>3210111
>можно в него покодировать
Кодировать можно, а декодировать - хуй. Поэтому
>Я не пойму vvc вышел или нет
Нет, не вышел.
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 19:09:02 3210121 174
>>3210116
>Кодировать можно, а декодировать - хуй. Поэтому
Да ну. Есть же софтверный плеер какой-нибудь. Хотя пока в ffmpeg не запихнут, так и не будет наверное. Потому что почти все плееры юзают ffmpeg.
>Нет, не вышел.
Посмотрел, вышел то еще в 2020 по сути. https://github.com/fraunhoferhhi/vvenc. Уже версия 1.6.
Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 19:21:21 3210122 175
>>3210121
>Есть же софтверный плеер какой-нибудь
"Какой-нибудь" - ключевое слово. По факту никакой. Ни mpv, ни ffmpeg, ни конусы и дауны, вангую, тоже.

>Нормально кстати проц грузит, поставил на 12 потоков и ровно до 50% грузит, мой 12/24 проц, в отличие от этих ав1.
А потом что? Чем открывать будешь?
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 19:25:56 3210125 176
>>3210122
vlc плагин какой-то есть https://code.videolan.org/videolan/vlc/-/issues/27055
но у меня не получается его завести
есть еще tencent O266, но мне лень компилить сурс с помощью докера.
Беда прям какая-то, за 2 года могли и допилить.
Аноним (Microsoft Windows 10: Palemoon) 27/09/22 Втр 19:27:34 3210126 177
>>3210125
Куда спешишь? Расслабься, не уйдёт от тебя нескодированное видео, скодируешь, когда будут декодеры.
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 19:34:26 3210129 178
mXnxOtBRrW.png 79Кб, 1278x498
1278x498
>>3210126
Так я уже скодировал. 2 секунды в 60 фпс, 210 фреймов. Судя по гитхабу пресет slow чуть медленнее пресета x265 placebo. В общем, у них там работа ведется, и кодек реально очень хорошо оптимизируется, в сравнении с прошлыми версиями.
Можно сбилдить vlc с поддержкой vvdec, но снова лень чет разворачивать всё.
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 19:40:51 3210130 179
>>3210129
Когда завезут поддержку в mpv?
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 20:39:13 3210139 180
>>3210130
хз скомпилить самому с libvvdec
Аноним (Linux: Firefox based) 27/09/22 Втр 21:59:21 3210169 181
image.png 25Кб, 435x92
435x92
> 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.

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

У aomenc с этими техниками беда — он по дефолту тюнит под PSNR, а с другими метриками у него какие-то непонятки: то их надо включать в билд, то они замедляют кодирование… Говорят есть ещё форк psyaom, не помню как именно он назывался, но мне лень пердолиться с ним, тем более что меня и ванильный aomenc устраивает.
Аноним (Microsoft Windows 10: Palemoon) 27/09/22 Втр 22:28:20 3210183 184
>>3210169
Что это за пиздец? На каком разрешении, на каких скоростях и прочая и прочая
> Ну и кому нужен такой кодек
А кому нужно что-то выше h264? Тем, у кого проблемки с шириной канала(ограничение на размер прикрепа в посте)/сверхвысокие разрешения, в которых h264 не эффективен, ввиду малого размера блоков, для 1080p это всё пустое баловство и 60% большей эффективности, при сравнимом качестве и адекватном битрейте там наберётся едва ли.
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 22:46:40 3210187 185
>>3210169
Что vp9, что av1 мылит я ебал. Даже в 4:4:4 деталей не остается, в сравнении с x264.
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 22:47:23 3210188 186
>>3210169
ссылку откула взял вдруг версии энкодеров старые.
Аноним (Microsoft Windows 10: Palemoon) 27/09/22 Втр 22:48:03 3210189 187
>>3210187
>мылит я ебал
Таков путь!
Аноним (Linux: Firefox based) 27/09/22 Втр 22:49:44 3210191 188
Аноним (Microsoft Windows 10: Chromium based) 27/09/22 Втр 22:55:44 3210193 189
image.png 249Кб, 2105x1321
2105x1321
image.png 200Кб, 2038x1320
2038x1320
image.png 262Кб, 2131x1400
2131x1400
image.png 217Кб, 2160x1394
2160x1394
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 23:23:06 3210196 190
>>3210182
Про психовизуальное восприятие не знал. Градиенты не кодировал, сказать не могу.
>он по дефолту тюнит под PSNR
PSNR весит чуть меньше, но на глаз ощутимо хуже чем VQ (--tune 0). Я ещё удивился, почему его по дефолту не ставят.
>а с другими метриками
метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
>то они замедляют кодирование
Разве?
>Говорят есть ещё форк psyaom
Не слышал о таком. Малопопулярные форки доставляют много проблем - мало кто ловит ошибки в них и проводит тесты.
Аноним (Linux: Firefox based) 27/09/22 Втр 23:36:39 3210198 191
>>3210196
> метрикамИ, несколько их что ли? PSNR противопоставляется VQ, ничего другого.
Я про aomenc, если что.
Аноним (Microsoft Windows 10: Firefox based) 27/09/22 Втр 23:42:10 3210199 192
>>3210198
Есть полный список метрик?
Аноним (Linux: Firefox based) 28/09/22 Срд 00:12:26 3210205 193
image.png 7Кб, 1050x47
1050x47
Аноним (Microsoft Windows 10: Chromium based) 01/10/22 Суб 13:50:02 3211086 194
Настройки X
Ответить в тред X
15000
Добавить файл/ctrl-v
Стикеры X
Избранное / Топ тредов