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

Программы

Ответить в тред Ответить в тред
Check this out!
<<
Назад | Вниз | Каталог | Обновить | Автообновление | 441 76 150
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
Аноним (Microsoft Windows 10: Chromium based) 20/09/22 Втр 20:05:10 3208325 41
>>3208298
>Че? У меня релиз [email protected] бит, нужно сделоть [email protected] бит. Я спрашиваю как это сделать, вы городите чушь.
Зачем это делать во-первых? Ты постить куда-то хочешь в инет или чо?
Аноним (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
Аноним (Google Android: Mobile Safari) 01/10/22 Суб 14:33:43 3211108 195
Аноним (Microsoft Windows 10: Chromium based) 01/10/22 Суб 16:46:26 3211156 196
>>3211108
Если crf повышает значение в динамичных сценах, то почему в них наоборот выше битрейт, чем в статичных?
Аноним (Linux: Firefox based) 01/10/22 Суб 17:07:53 3211161 197
>>3211156
Потому что если повышать ещё сильнее — картинка посыпется на квадраты.
Аноним (Microsoft Windows 10: Chromium based) 01/10/22 Суб 18:44:23 3211198 198
>>3211161
Но ведь можно просто не повышать.
Аноним (Linux: Firefox based) 01/10/22 Суб 19:05:45 3211214 199
>>3211198
Тогда это будет режим с постоянным квантователем, и весить такой файл будет больше.
Аноним (Microsoft Windows 10: Chromium based) 01/10/22 Суб 19:13:37 3211217 200
>>3205384 (OP)
> https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg кодирование гайд.md
> Указаны два параметра которые рекомендуются в руководстве для повышения качества видео.
Ты сам разбирался, что они значат, или просто на авторитетный источник ссылаешься (он не открывается, кстати)? Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше при прочих равных. По качеству никакой разницы, всё равно CRF 35.
Аноним (Google Android: Mobile Safari) 01/10/22 Суб 19:58:02 3211228 201
>>3211217
В смысле не открывается
Ну да, ссылаюсь. Параметры из документаций официальных набирал, и по опыту.
> Из-за irefresh-type=1 видео очень долго перематывается и размер в полтора раза больше
Серьёзно, можешь показать пример? Странно
Аноним (Linux: Chromium based) 02/10/22 Вск 00:57:57 3211324 202
можно ли сделать красивый плейлист в виде

Album
[04:20] 1. Artist - Song

с помощью ffprobe или ffmpeg?
Аноним (Linux: Firefox based) 02/10/22 Вск 01:04:38 3211325 203
>>3211324
Проще вручную m3u плейлист в блокноте написать.
Аноним (Linux: Chromium based) 02/10/22 Вск 01:06:28 3211326 204
>>3211325
не, нужен именно текстовый список для оформления раздачи на рутрекере.
Аноним (Linux: Firefox based) 02/10/22 Вск 01:11:23 3211327 205
>>3211326
ХЗ. Тут с регулярками баловаться надо, а где и как это делать что-бы получить текстовик не знаю.
Аноним (Google Android: Mobile Safari) 02/10/22 Вск 07:44:17 3211352 206
Аноним (Microsoft Windows 7: Firefox based) 02/10/22 Вск 08:53:24 3211361 207
>>3199130 →

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

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

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

>>3201419 →

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

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

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

>>3201460 →

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

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

>>3201691 →

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

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

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

>>3201703 →

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

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

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

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

>>3201850 →

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

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

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

>>3202778 →

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

XnView MP

>>3205312 →

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

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

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

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

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

>>3208639

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

>>3205319 →

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

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

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

Опосля первого появления десятибитности цвѣтовыхъ компонентов в видеофайлах (рѣчь идёт о появлении профиля «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 в Википедии).

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

>>3208560

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

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

>>3209059

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

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

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

>>3209102

> keyint:10s

Не «:», а «=».

>>3209133

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

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

>>3209475

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

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

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

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

>>3209667

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

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

Ждём до ≈2032 года.
Аноним (Google Android: Mobile Safari) 02/10/22 Вск 10:26:51 3211371 208
Аноним (Google Android: Mobile Safari) 02/10/22 Вск 10:39:19 3211373 209
>>3211361
>только что ускорили
>сначала сломали скорость, а потом опять вернули
>ускорили
Аноним (Google Android: Mobile Safari) 02/10/22 Вск 10:42:49 3211376 210
>>3211373
Алсо этот чмондель указывает шестикратную разницу между пресетом 7 и пресетом 4
Аноним (Microsoft Windows 7: Firefox based) 02/10/22 Вск 11:23:52 3211385 211
screenshot.png 4Кб, 562x208
562x208
Тебя в начальной школе научили слову «чмондель», >>3211376, но забыли научить читать табличные данные?
Аноним (Microsoft Windows 10: Firefox based) 02/10/22 Вск 11:28:36 3211386 212
>>3211385
Нахуя ты себя своим же скрином прикладываешь, долбоебина?
Аноним (Microsoft Windows 10: Firefox based) 02/10/22 Вск 11:33:54 3211387 213
1664699634000.png 76Кб, 259x194
259x194
>>3211386
А бля, и правда, до
>1,087
я не дочитал
Аноним (Microsoft Windows 7: Firefox based) 02/10/22 Вск 11:50:26 3211390 214
Дочитывать надо.
Аноним (Microsoft Windows 10: Firefox based) 02/10/22 Вск 11:52:15 3211392 215
Никак не отменяет того, что это всего лишь фикс регрессии, чмондель.
Аноним (Linux: Firefox based) 02/10/22 Вск 13:27:44 3211419 216
>>3211361
> > Когда же декодер добавят в FFmpeg?
> Когда закончится срок дѣйствія патента.
Нахер столько ждать. Лучше забыть и не вспоминать.
Аноним (Microsoft Windows 10: Firefox based) 02/10/22 Вск 14:27:32 3211465 217
>>3211361
>под Windows только что ускорили ШЕСТИКРАТНО
Почему числа под люниксам в четыре раза больше. Как ос связана со скоростью кодирования?
Аноним (Google Android: Mobile Safari) 02/10/22 Вск 17:31:36 3211533 218
>>3211361
>такие адски заумныя, как >>3205534, поэтому знание смысла слов «дисперсия» или «нормирование» и «энергетический показатель» не потребуется
>сводится к приписыванию двух нулей в новых младших разрядах каждого компонента. Так как алгоритмы видеосжатия приучены искать и устранять информационную избыточность, то задача сжатия этих нулей (на основе их предсказуемости, математически проявляющей себя отсутствием высокочастотных компонентов в результатах дискретного косинусного преобразования) не представляет большой трудности — слѣдовательно, реальный рост объёма видеофайла получается меньшим, чѣмъ был бы пропорциональный росту числа разрядов
Действительно, зачем нужны адские заумия для понтующихся имитацией дореволюционной орфографии, особенно, если они не понимают как работает ДКП и прочие интегральные ортогональные преобразования.
Аноним (Microsoft Windows 10: Chromium based) 02/10/22 Вск 20:40:13 3211578 219
>>3211385
Что это за картинка, почему на винде так медленно?
Аноним (Microsoft Windows 10: Firefox based) 02/10/22 Вск 23:54:06 3211628 220
Аноны, вопрос может не совсем по теме, но суть такая.
Есть пейлист на ютубе с видео уроками. Самое важное там это аудио, а видео это по сути набор слайдов.
Хочется пейлист себе сохранить, но так чтобы он не занимал много места.

Как быть в такой ситуации? Слишком низкое качество картинки может не подойти т.к. там текст и потом его не поймёшь.
Аноним (Microsoft Windows 10: Chromium based) 02/10/22 Вск 23:56:23 3211630 221
Аноним (Linux: Firefox based) 03/10/22 Пнд 00:15:13 3211634 222
>>3209903
Для подтверждения что он не наебал с ответами, в старом архиве то же самое. Ты конкурсы в интернете никогда не видел? Без подобного пруфа организатор может изменить ответы по своему желанию.
Аноним (Microsoft Windows 10: Firefox based) 03/10/22 Пнд 02:29:42 3211646 223
>>3211628
>а видео это по сути набор слайдов.
-vf mpdecimate
Если два последовательных кадра дублируются, оно расходует почти 0 битрейта.
Аноним (Google Android: Mobile Safari) 03/10/22 Пнд 10:13:27 3211703 224
Как mkv и ass закодить в mp4? Чтоб субтитры не на видео наложились, а чтобы можно было их переключать/выключать.
Аноним (Google Android: Firefox based) 03/10/22 Пнд 10:18:36 3211706 225
>>3211703
Никак. Потому что mp4 не нужен, это говноформат без поддержки кодеков и с двойной записью на диск ради быстрого запуска (-movflags +faststart).
Аноним (Linux: Firefox based) 03/10/22 Пнд 12:44:07 3211755 226
>>3211703
Можешь рассказать почему такая задача возникла?
Аноним (Microsoft Windows 7: Firefox based) 03/10/22 Пнд 13:28:03 3211780 227
>>3211703

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

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

Пиздец, невозможно общаться нормально.
Аноним (Microsoft Windows 10: Chromium based) 03/10/22 Пнд 14:13:56 3211790 229
>>3211703
Мне кажется только рядом с файлом с таким же именем положить, а плеер сам подхватит.
Аноним (Google Android: Firefox based) 03/10/22 Пнд 16:20:29 3211832 230
Каким поехавшим нужно быть, чтобы муксировать в mp4 а не в mkv?
Аноним (Google Android: Mobile Safari) 03/10/22 Пнд 16:50:15 3211838 231
>>3211706
Ффмпегопроблемы, остальной софт умеет это делать без двойной записи
Аноним (Google Android: Firefox based) 03/10/22 Пнд 16:58:18 3211842 232
>>3211838
Может быть, остальной софт имеет все те же функции и кодеки, что ffmpeg, и такой же бесплатный?
Аноним (Microsoft Windows 10: Chromium based) 03/10/22 Пнд 18:42:01 3211853 233
image.png 246Кб, 499x520
499x520
capture.mkv 5100Кб, 1920x1080, 00:01:10
1920x1080
>>3211228
> В смысле не открывается
image.png
> можешь показать пример?
capture.mkv
Аноним (Google Android: Mobile Safari) 03/10/22 Пнд 18:50:46 3211854 234
Сколько времени примерно займет кодирование полуторачасового фильма в фул хд на впсочке с одним некроядром и 512 мб памяти? Стоит ли это вообще того?
Аноним (Google Android: Mobile Safari) 03/10/22 Пнд 18:51:27 3211855 235
Аноним (Microsoft Windows 10: Chromium based) 03/10/22 Пнд 18:57:23 3211856 236
Аноним (Microsoft Windows 10: Chromium based) 03/10/22 Пнд 19:31:58 3211873 237
>>3211628
Они уже на ютубчики сразу должны быть пережаты как надо, чтобы минимум места занимать. Гугл же не тупые.
Аноним (Microsoft Windows 10: Firefox based) 04/10/22 Втр 01:17:42 3212022 238
>>3211873
В принципе да, это тоже может подойти. Скачал длинный видос 30мин+ и не в самом лучшем качестве, но смотрибельный, вышло 31мб.
Аноним (Google Android: Mobile Safari) 04/10/22 Втр 01:51:13 3212027 239
>>3211873
Оно пересжато как надо им, максимально некачественно, с минимальным качеством и размером. Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
Аноним (Microsoft Windows 10: Palemoon) 04/10/22 Втр 01:52:13 3212028 240
16568402275590.mp4 444Кб, 480x480, 00:00:06
480x480
Аноним (Microsoft Windows 10: Chromium based) 04/10/22 Втр 19:25:34 3212224 241
>>3212027
>Если взять исходник можно сжать самому с намного лучшим качеством при таком же размере
И как ты это сделаешь, сверхразум? Как будто этого никто не знает.
Аноним (Linux: Firefox based) 04/10/22 Втр 19:35:19 3212228 242
>>3212224
Ютуб транскодирует асиками. Транскод асиками даёт возможность транскодировать очень быстро, но не очень качественно.
Аноним (Microsoft Windows 10: Palemoon) 04/10/22 Втр 19:43:37 3212229 243
>>3212228
Он имеет ввиду, что исходников от гугла ты не допросишься.
Аноним (Google Android: Mobile Safari) 04/10/22 Втр 20:15:56 3212241 244
>>3212228
> но не очень качественно.
А это уже зависит от асика.
Аноним (Linux: Firefox based) 04/10/22 Втр 22:35:54 3212299 245
>>3212241
Асики от nvidia едва доползли до однопрогодного -preset medium, если говорить о h264. Новейшие асики в видяхах от Intel кодируют AV1 с эффективностью аналогичной x264 -preset veryslow. Для реалтайма может и прорыв, но с кодированием на CPU на медленных настройках не сравниться.
Аноним (Google Android: Mobile Safari) 05/10/22 Срд 07:43:45 3212372 246
>>3212299
Ты думаешь там кто-то что-то кодирует на асиках потребительских видеокарт?
Аноним (Microsoft Windows 10: Яндекс браузер) 05/10/22 Срд 16:07:19 3212465 247
Аноны, подскажите, как сделать так, чтобы в конце видео не образовывалось лишних секунд?
Допустим, когда после -r я ставлю 10, то всё нормально
А когда 1 -- остаётся десяток-другой тишины.
Но во втором случае всегда намного меньше веса.
Как собирать шебмы с еденицей фпс и чтобы выходило ровно по времени?

Пример команды:
ffmpeg -r Х -loop 1 -i картинка -i музыка.wav -c:a libopus -b:a 128K -c:v libvpx-vp9 -strict -2 -shortest выход.webm
Аноним (Microsoft Windows 10: Firefox based) 05/10/22 Срд 16:22:10 3212474 248
>>3212465
По крайне мере стоит попробовать явно указать -t
Если это поможет и если автоматизировать - я бы скрипт на питоне сделал, который получает длительность и вписывает её. Может быть есть способ как-то через командную строку указать, вроде -shortest - я без понятия.
Ещё есть же кодеки поддерживающие переменный fps, думаю через это можно в конце добавить кадр с длительностью нужной.
Аноним (Microsoft Windows 10: Chromium based) 05/10/22 Срд 17:11:34 3212482 249
>>3212465
Это баг даже не -r вроде, а самого ffmpeg когда пытаешься залупить картинку. Хотя мб ты нашел причину, просто ставь -t под длительность музыки.
Аноним (Microsoft Windows 10: Яндекс браузер) 05/10/22 Срд 17:24:20 3212490 250
>>3212474
>>3212482
Капец затуп, конечно. Совсем про -t забыл.
Спасибо, попробую -- отпишусь.
Аноним (Microsoft Windows 10: Chromium based) 05/10/22 Срд 17:53:12 3212505 251
>>3212465
Указывай ещё
-g 9999
-pix_fmt yuv420p
-crf сколько надо
Аноним (Linux: Firefox based) 05/10/22 Срд 19:19:05 3212522 252
>>3212505
> -g 9999
Зачем? Я с тем же успехом могу тупо один фрейм с картинкой закодировать. Что так что этак прокрутка идёт по пизде.
Аноним (Microsoft Windows 10: Firefox based) 05/10/22 Срд 23:16:52 3212563 253
Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен? Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
Аноним (Microsoft Windows 7: Firefox based) 05/10/22 Срд 23:19:45 3212564 254
>>3212563
> Поясните за реалтайм на svtav1. Он же не умеет кодировать ни в rgb, ни в 4:4:4, нахуя он нужен?
Он все еще в активной разработке.

> Проще же реально использовать всё тот же x264, пусть и с чуть большим битрейтом, зато без мыла.
Используй.
Аноним (Microsoft Windows 10: Firefox based) 05/10/22 Срд 23:28:03 3212568 255
>>3212564
>Он все еще в активной разработке.
Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
Аноним (Google Android: Mobile Safari) 06/10/22 Чтв 07:03:24 3212622 256
>>3212474
>>3212482
А как (куда) вписывать -t при склеивании? Выдаёт ошибку, мол, no such a file or directory.
Аноним (Google Android: Mobile Safari) 06/10/22 Чтв 07:08:09 3212626 257
>>3212622
>tduration(input/output)

> When used as an input option (before-i),
> limit thedurationof data read from the input file.
Вопрос снят, я жопочтец.
Аноним (Microsoft Windows 7: Firefox based) 06/10/22 Чтв 09:26:15 3212636 258
>>3212568
> Окстись, он уже давно перешагнул за релиз 1.0.0, пилят его уже хуй знает сколько лет, в него уже не будут добавлять поддержку новых форматов, если но добавили до сих пор.
Ядро Linux пилят 20+ лет, перешагнуло 6.0.0, все еще в активной разработке. Дальше что?
Аноним (Google Android: Mobile Safari) 06/10/22 Чтв 09:31:59 3212637 259
>>3212636
Хомо сапиенс эволюционировал уже как 50 тысяч лет, изобрел спермерочку и всё ещё активно эволюционирует. Дальше что?
Аноним (Microsoft Windows 10: Firefox based) 06/10/22 Чтв 15:48:53 3212756 260
А ваш чудо ffmpeg может прям напрямую из видеофайла сразу вырезать нужный кусок без ёбли и кучи команд? Если да, тогда подумаю о переходе, смотрю много контента и много сцен бывает, которые хочется вырезать и отправить подружке
Аноним (Microsoft Windows 10: Chromium based) 06/10/22 Чтв 17:55:12 3212788 261
>>3212622
В аутпут лучше в параметры кодироваания видео после основных.
Аноним (Microsoft Windows 10: Chromium based) 06/10/22 Чтв 17:56:30 3212789 262
>>3212756
avidemux резка с ключевого кадра.
Аноним (Microsoft Windows 10: Firefox based) 06/10/22 Чтв 21:58:50 3212855 263
Какой максимальный размер шебм на харкаче?
Аноним (Microsoft Windows 10: Chromium based) 06/10/22 Чтв 22:18:34 3212860 264
>>3212855
В правом нижнем углу формы ввода написано для каждой доски.
Аноним (Microsoft Windows 7: Firefox based) 07/10/22 Птн 06:33:44 3212899 265
>>3212505

> -pix_fmt yuv420p

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

Это экономия на спичках.
Аноним (Microsoft Windows 10: Palemoon) 07/10/22 Птн 06:57:21 3212900 266
>>3212899
Дело скорее в совместимости, охват утюгов, которые декодируют 420 больше.
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 10:25:43 3212921 267
image.png 13Кб, 617x352
617x352
Пачаны, как в ффмпеге задать очередь? у меня есть список команд, но по одной заебался вводить. Спасибо.
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 10:30:26 3212922 268
>>3212921
и ещё ест трабла, первые 1-2 минуты видоса очень пиксельные, потом всё идеально, как фиксить? без поднятия битрейта желательно, конверчу на долгое хранение
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 10:30:44 3212923 269
image.png 447Кб, 1025x578
1025x578
Аноним (Microsoft Windows 10: Firefox based) 07/10/22 Птн 11:19:52 3212932 270
>>3212921
Там одинаковые настройки и только названия разные?
Батник, не? Или скрипт твоей ос, или просто на питоне через subprocess?
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 11:27:16 3212935 271
>>3212932
не там есть траблы с сабами и аудио, надо вручную выбирать дорожки, это заёбно но я составляю такие списки заранее и потом по одной серии конверчу, я хз даже как через батник, типа каждую серию в отдельный тхт и как то потоком поставить?
Аноним (Linux: Firefox based) 07/10/22 Птн 11:50:16 3212940 272
>>3212922
Не кодировать в CBR. Лучше поставь двухпроходный VBR.
Аноним (Microsoft Windows 10: Firefox based) 07/10/22 Птн 11:53:57 3212942 273
изображение.png 1Кб, 236x23
236x23
изображение.png 1Кб, 230x22
230x22
Из 2мб видео эта хуйня выгнала мне 13мб гифку. Ебать. Как ето возможно вообще, я гиф делал наоборот чтобы меньше места занимало.
Аноним (Linux: Firefox based) 07/10/22 Птн 12:19:15 3212951 274
>>3212942
Ты идиот? Гифки это древний формат с древними принципами сжатия. И вообще гифкам место на свалке истории. Жаль им до сих пор не придумали адекватной замены.

Но сравнивать древний формат из восьмидесятых с современными видеокодеками это конечно шиза.
Аноним (Microsoft Windows 10: Palemoon) 07/10/22 Птн 12:21:34 3212952 275
16495392137830.png 698Кб, 640x640
640x640
>>3212942
>гиф
>меньше места занимало
Я вижу вы тоже, перекодировщик культурный.
Аноним (Microsoft Windows 10: Firefox based) 07/10/22 Птн 12:38:34 3212956 276
>>3212951
Нет, ты идиот. Дальше не читал, иди нахуй.

>>3212952
Да. Советы будут?
Аноним (Microsoft Windows 10: Palemoon) 07/10/22 Птн 12:47:19 3212959 277
16459132472280.jpg 12Кб, 292x228
292x228
>>3212956
>Советы будут
Как сделать из видео набор картинок? Ты неплохо справился.
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 13:44:05 3212966 278
1622068623711.jpg 16Кб, 230x219
230x219
>>3212942
> я гиф делал наоборот чтобы меньше места занимало
Аноним (Google Android: Firefox based) 07/10/22 Птн 16:00:33 3213001 279
>>3212921
echo "команда 1" && echo "команда 2"
Аноним (Microsoft Windows 10: Chromium based) 07/10/22 Птн 17:04:59 3213013 280
>>3212942
Потому что гиф это ряд картинок jpg буквально. допустим jpg весит 500кб в ней 60 кадров всего. Вот и умножай сколько получится - 30мб
Аноним (Microsoft Windows 10: Firefox based) 07/10/22 Птн 17:17:54 3213019 281
>>3213013
До меня правда только что начало доходить, что в исходнике кадры пожаты 264-м, в то время как гиф ничего не жмет сам по себе, только если скажешь ффмпегу жать твою гифку с доп. параметрами.

Обязательно меня идиотом называть, если мне раз в сто лет пришло сделать такую штуку и я сходу не разобрался, что к чему? Почему жизнь ко мне так несправедлива и жестока.
Аноним (Linux: Firefox based) 07/10/22 Птн 17:45:08 3213022 282
>>3213019
Тебе не нужны гифки для сжатия. Методы компрессии формата GIF устарели, и не могут быть использованы для транскодирования видео в сколько нибудь приемлемом качестве.
Аноним (Linux: Firefox based) 07/10/22 Птн 17:48:44 3213023 283
>>3213013
Ну у джипега перед гифкой есть преимущество: ДКП. А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Аноним (Microsoft Windows 7: Firefox based) 07/10/22 Птн 18:08:44 3213027 284
>>3213023
> А формат GIF не может нормально сжать ничего кроме схематично нарисованных картинок.
Потому что GIF внезапно loseless (LZW). В отличие от.
Аноним (Microsoft Windows 10: Firefox based) 08/10/22 Суб 09:19:21 3213184 285
изображение.png 76Кб, 816x474
816x474
>>3212935
>надо вручную выбирать дорожки
Совсем вручную? Ну, если там разумное количество файлов, то просто скопировать строчку нужное число раз и вставлять номера дорожки. Если безумное, то ты всё-равно на ручной просмотр времени много потратишь.
Но даже без скриптов ты можешь просто список файлов сделать с номерами, и через замену заменить разделители на остальные параметры.

>типа каждую серию в отдельный тхт и как то потоком поставить?
Какой txt?
Просто кучу команд пишешь и запускаешь, оно их само по очереди все сделает, ещё можешь загуглить что такое shift и %1 в батниках, ещё быстрее сделаешь. Если хочешь вместе, то нужно либо команду для cmd запуска в отдельном потоке искать, либо через питон. И ещё всё зависнет, так как после десяти одновременных экземпляров даже мышка будет плохо двигаться.
Аноним (Microsoft Windows 10: Firefox based) 08/10/22 Суб 09:53:54 3213188 286
>>3212942
Пробуй делать APNG. Многие забывают про этот кошерный формат, в то время как слово гифка стало маркером быдла, как и эмэрзе.
Аноним (Microsoft Windows 10: Firefox based) 08/10/22 Суб 18:26:08 3213419 287
>>3212942
> Жаль им до сих пор не придумали адекватной замены.
APNG, Animated WebP.
Аноним (Linux: Firefox based) 08/10/22 Суб 18:46:26 3213426 288
>>3213419
> APNG
Те же методы сжатия что и у GIF. Единственное преимущество перед GIF — поддержка 24-битного цвета.
> WEBP
Не знаю чего там напридумали инженеры из гугла, но WEBM из VP8 будет весить меньше, чем WEBP. Экономия от пережатия GIF в lossy WEBP составляет какие-то жалкие 25-50%.

А если пережать в H264/VP9, то полученный файл будет в разы меньше гифки. Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
Аноним (Microsoft Windows 10: Firefox based) 08/10/22 Суб 21:12:52 3213492 289
>>3213426
>Единственное преимущество перед 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%.


> Но если открыть этот файл в браузере, то там будет видна пауза между повторами.
Вроде бы какой-то флаг кодирования есть в одном из форматов...
Аноним (Microsoft Windows 10: Palemoon) 08/10/22 Суб 21:14:09 3213493 290
16464095199430.gif 785Кб, 250x300
250x300
>>3213492
> Это всё ещё не исключает того, что webp намного юзабельнее чем gif, просто в десятки раз
Запости, хочу глянуть.
Аноним (Microsoft Windows 10: Firefox based) 08/10/22 Суб 21:27:53 3213497 291
>>3213493
Анимированный вебп нельзя запостить на сосаче.
Аноним (Linux: Firefox based) 08/10/22 Суб 21:37:51 3213499 292
>>3213492
> А vp8 запросто и 10 секунд "сложного" видео покажет, так что будет понятно что происходит на экране. Фигню ты сказал про экономию в 25-50%.
VP8 да, Анимированный WEBP не факт что вообще влезет в твои лимиты. Опять же, ты даже не пробовал сжимать.
Аноним (Microsoft Windows 10: Palemoon) 08/10/22 Суб 21:38:25 3213500 293
16312011026400.gif 774Кб, 334x298
334x298
>>3213497
Ненамного юзабльнее получается?
Аноним (Linux: Firefox based) 08/10/22 Суб 21:42:01 3213502 294
>>3213500
Ты на двач не ориентируйся. Хотя если тебе надо постить на двачах, то всё что не PNG/JPEG/GIF/WEBM/MP4 неюзабельное говно.
>>3213492
> Вроде бы какой-то флаг кодирования есть в одном из форматов...
Интересно было бы почитать по этому поводу.
Аноним (Microsoft Windows 10: Palemoon) 08/10/22 Суб 21:57:39 3213511 295
16342059346220.jpg 36Кб, 724x724
724x724
>>3213502
> Хотя если тебе надо постить на двачах
А что с ними ещё делать? Коллекционировать и рассматривать долгими зимними вечерами? И эти форматы постятся не только на двачах, потому странно хранить изображения в форматах, которые используют 3.5 софтовых калеки.
Аноним (Microsoft Windows 10: Chromium based) 08/10/22 Суб 22:00:05 3213514 296
Разве поддержку webp не сделали с новым движком?
упд. Мда кал нельзя запостить, еще и поддержку mp3 пидорнули.
Аноним (Linux: Firefox based) 08/10/22 Суб 23:57:52 3213546 297
>>3213514
Зато новый движок не падает постоянно с 502 Плохие Ворота. Хотя нет, подождите...
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 00:06:40 3213552 298
image.png 773Кб, 1280x720
1280x720
Вопрос пользователям ff2mpv, это нормально что для запуска данного 30 секундного видео с ютуба в mpv требуется около 5 секунд? Так и должно быть или я что-то не так сделал, чому так долго?

https://www.youtube.com/watch?v=dap5lEuS5uM
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 00:08:04 3213553 299
>>3213552
Нормально. link2mpv так же по времени, хоть там и сишка нативная на клиенте.
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 00:12:54 3213554 300
>>3213552
Ну так пока yt-dlp одуплится, пока mpv всё это прожуёт, секунд 5 и пройдёт. Сам попробуй введи команды в консольку и посмотри сколько по времени весь процесс займёт.
На линуксе кстати быстрее всё происходит.
Аноним (Microsoft Windows 10: Chromium based) 09/10/22 Вск 07:25:37 3213619 301
Зачем нужна WebM, если это кастрированная Matroska? Google явно не по приколу её разработал, в чём тогда смысл?
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 10:51:20 3213651 302
>>3213553
Так это же ютубовское ограничение скорее, а не сишки или ещё чего.

>>3213619
Во-первых, немного полегче контейнер, во-вторых предположу что специально.
Написать что бравзер поддерживает webm - норм. А написать браузер поддерживает mkv, но только видеодорожки форматов h264, vp8, ... и аудиодорожки форматов ... - это намного недружелюбнее для пользователей.
Спроси у обывателя какие форматы поддерживает его видео плеер - он скажет что mp4, avi и что там ещё бывает. А при упоминании avc или h264 скажет что первый раз слышит.
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 11:51:08 3213671 303
>>3213553
>>3213554
А то что подгрузка при перематывании стрима дольше, чем на ютубе тоже нормально?
Аноним (Microsoft Windows 10: Chromium based) 09/10/22 Вск 13:49:36 3213693 304
>>3213651
Что специально? Ну да, я и говорю, что не случайно, только зачем делать матрёшку, которая умеет меньше оригинала?
Картинка в разных вьюверах выглядит по-разному Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 15:48:40 3213725 305
Есть два вьювера - Xnview и Honeyview. В них, что с фильтрами, что без фильтров, картинка отличается - она как-будто поделена на огромные области, которые стыкуются между собой и как бы дорисовывают детали, либо съедают их. Деформируют картинку на пол процента, сохраняя суть, но микро-формы по пикселям отличаются. Почему так? Где картинка правильнее?
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 15:52:15 3213728 306
>>3213725
С масштабом 100% уже выглядят почти одинаково. Но всё-равно отличаются - по краям смещение кадра на пару пикселей, как будто обрезали. И сама область с картинкой на чёрном фоне сдвинута на пару пикселей.
Аноним (Microsoft Windows 10: Chromium based) 09/10/22 Вск 17:49:41 3213754 307
>>3213552
Potplayer ytdlp открывает сразу за 1-2 сек, но в общем всё вместе пока ytdlp догрузит тоже 5 сек.
Аноним (Microsoft Windows 10: Chromium based) 09/10/22 Вск 18:34:01 3213760 308
Можно ли в webm для ретардов сделать нормализацию звука?
Аноним (Microsoft Windows 10: Firefox based) 09/10/22 Вск 21:48:19 3213794 309
изображение.png 3Кб, 433x51
433x51
>>3213760
Вряд ли там галочка есть, но вроде бы там была строчка дополнительных параметров для ffmpeg, вот туда попробуй что-то вроде этого дописать.
https://ffmpeg.org/ffmpeg-filters.html#toc-dynaudnorm
Ещё фильтр loudnorm поищи.
Аноним (Microsoft Windows 10: Chromium based) 10/10/22 Пнд 02:43:33 3213871 310
>>3213794
> No such filter: 'loudnorm'
не робит
Аноним (Google Android: Mobile Safari) 10/10/22 Пнд 08:25:06 3213892 311
>>3213871
Пробуй пока не получится, строка ретарда вроде как напрямую скармливается ффмпегу.
Аноним (Microsoft Windows 10: Firefox based) 10/10/22 Пнд 09:41:13 3213901 312
>>3213871
Хм, может внутренний ffmpeg нужно поменять на более новый.
Там же при сборке можно отключить не нужное, может быть и этот фильтр отключили...

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

>>3213892
Нет, ему же прямо написало, что оно поняло название фильтра, но фильтра такого не обнаружило.
Аноним (Google Android: Firefox based) 10/10/22 Пнд 11:56:19 3213922 313
Челы, показывайте ваши команды,
Аноним (Google Android: Mobile Safari) 10/10/22 Пнд 12:01:05 3213923 314
Аноним (Microsoft Windows 7: Firefox based) 10/10/22 Пнд 15:38:52 3213961 315
>>3213923
> At least one output file must be specified
Аноним (Microsoft Windows 10: Chromium based) 10/10/22 Пнд 16:33:52 3213978 316
>>3213901
> Хм, может внутренний ffmpeg нужно поменять на более новый.
а как?
> сделать через чистый ffmpeg, или попробовать внутренний поменять на новый отдельно скаченный
нихуя не получается, ничего не понимаю...
Аноним (Microsoft Windows 7: Firefox based) 10/10/22 Пнд 20:37:57 3214053 317
>>3213725

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

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

>>3213426

> APNG

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

Бредятина!

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

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

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

Также ерунда: во-первых, не единственное, а во-вторых, PNG поддерживает и 48-битный цвѣтъ.
Аноним (Microsoft Windows 10: Firefox based) 10/10/22 Пнд 20:44:45 3214055 318
>>3214053
>XnView MP
Да, он.

>Пиши подробности про XnView.
Да я свою претензию уже написал. Ещё могу сказать, что он, имхо, запускается дольше, и если нажать не ту клавишу, то вместо выхода из программы откроешь интерфейс эдакого проводника вместе с картинкой.
Аноним (Google Android: Mobile Safari) 11/10/22 Втр 09:38:29 3214140 319
>>3214053
> цвѣтъ.
Зачем ты пишешь неправильно?
Аноним (Linux: Firefox based) 11/10/22 Втр 12:32:14 3214172 320
>>3214053
> Во-первых, DEFLATE — это не LZW.
Да похуй. Lossless сжатие это последнее что меня интересует.
> Во-вторых, используются предикторы.
Которые предсказывают лишь 1 пиксел от 3-x или 4-x ближайших соседних пикселей, в противовес тому же VP8 где предсказывается макроблок из крайних пикселей соседних макроблоков. И это я ещё не говорю про AV1 где эти блоки могут быть переменного размера и к тому же могут иметь неквадратную форму.
Аноним (Microsoft Windows 10: Chromium based) 13/10/22 Чтв 17:28:25 3214991 321
Как быстро скачивать ютуб лайв стримы, которую после того, как он закончится, будет недоступен. ytdl+ffmpeg очень долго качает, потому что качает m3u8 и постоянно парсит hls куски, в общем долго кушает, еще и одним потоком похоже. пробовал 4kdownlaoder, но он как будто вообще не качает.
Аноним (Microsoft Windows 10: Chromium based) 13/10/22 Чтв 17:40:47 3214995 322
>>3214991
Он еще и качает с конца как бы, вот что хуже всего. Сейчас был стрим на 1 час и 40 мин, скачал 50 мин, и получается первых 50 минут нет.
Аноним (Microsoft Windows 10: Firefox based) 13/10/22 Чтв 21:19:35 3215043 323
Аноним (Microsoft Windows 10: Firefox based) 15/10/22 Суб 14:17:52 3215519 324
>>3205384 (OP)
Какой из гуев сегодня жив?
Немного полистал поиск на гитхабе, очень много тех кто уже по 2-3 года не обновлялся
Аноним (Microsoft Windows 10: Firefox based) 15/10/22 Суб 14:19:38 3215521 325
Аноним (Apple Mac: Chromium based) 16/10/22 Вск 17:29:35 3215878 326
1.mp4 1501Кб, 850x576, 00:00:12
850x576
Сделал вещицу вот.
Принимает на вход текстовый файл и картинку, результат видите.

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

Вопрос. Где это можно использовать?
Думал сделать канал в телеге или тиктоке, чтоб туда автоматически загружался каждый день видос, допустим, с топ новостью для из какого-то источника.. На этом идеи акончились.
Подкиншь мыслишек, анон?
Аноним (Microsoft Windows 7: Firefox based) 16/10/22 Вск 19:03:38 3215898 327
>>3215878
Говно без задач. Буквально. Еще и текст по всему экрану скачет. Пиздец просто.
Аноним (Apple Mac: Chromium based) 16/10/22 Вск 20:22:19 3215920 328
Аноним (Apple Mac: Chromium based) 17/10/22 Пнд 20:43:09 3216249 329
Screenshot 2022[...].png 134Кб, 1320x702
1320x702
Делаю аналог lofi hip-hop радио.
В бесконечном цикле скачиваю следующую песню с ютуба, стримлю ее в буфер, потом из буфера стримлю уже на ютуб.
Чуть-чуть идет, но потом прерывается..
Не могу понять, что за "Broken pipe".. Ничего не смог нагуглить.
Менял по разному размер буфера и битрейт выходного потока, но это без изменений.
Кикие мысли, анончик?


av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
size= 4kB time=00:00:00.16 bitrate= 195.8kbits/s speed=1.71e+03x
video:0kB audio:3kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 30.555555% Conversion failed! ERROR: [Errno 32] Broken pipe Exception ignored in: <_io.TextIOWrapper name='' mode='w' encoding='utf-8'> BrokenPipeError: [Errno 32] Broken pipe
Аноним (Microsoft Windows 10: Chromium based) 17/10/22 Пнд 23:25:18 3216320 330
>>3216249
Пайп в принципе через жопу работает как-то. Пытался последний раз, а он не в какую.
Аноним (Microsoft Windows 10: Firefox based) 20/10/22 Чтв 12:19:51 3217094 331
Подскажите пожалуйста
есть видео 1280x720.mp4 сделал гифку 300x300, в гифке черные полосы по бокам как покифксить?
Аноним (Microsoft Windows 10: Chromium based) 20/10/22 Чтв 13:15:50 3217115 332
>>3217094
Кропом. Скинь команду.
Аноним (Microsoft Windows 10: Chromium based) 20/10/22 Чтв 16:06:59 3217161 333
>>3205384 (OP)
Установился апдейт на MPHC, после чего пропал звук в вебмках.
Как фиксить?
Аноним (Microsoft Windows 10: Chromium based) 20/10/22 Чтв 18:35:13 3217197 334
Аноним (Microsoft Windows 10: Firefox based) 22/10/22 Суб 07:35:08 3217752 335
Аноним (Microsoft Windows 10: Firefox based) 22/10/22 Суб 13:13:32 3217841 336
image 297Кб, 959x530
959x530
>>3217752
> может подсказать как узнать координаты картинки чтобы знать какую именно область в видео мне нужно вырезать
Делай кроп хандбраке, там есть удобное превью с возможностью указать кроп on-the-fly. Не еби себе мозги с ффмпежей, он не создан для динамического редактирования видео.
Аноним (Linux: Firefox based) 22/10/22 Суб 13:21:11 3217844 337
>>3217752
Сделай скриншот кадра с хорошо различимой границей между видео и чёрной полосой.

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

Снова берёшь линейку и меряешь пиксели от верхнего угла до верхней направляющей. Это и будет твой «x». Потом меряешь линейкой расстояние от верхней направляющей до нижней направляющей. Это будет твой «h».
Аноним (Linux: Firefox based) 22/10/22 Суб 13:25:27 3217847 338
>>3217844
> Это и будет твой «y»
Извините, опечатался. Х это всё таки для обрезки по горизонтали, а не по вертикали. Так что это будет не X а Y.
Аноним (Google Android: Firefox based) 22/10/22 Суб 13:35:42 3217858 339
>>3217752
ffmpeg -hide_banner -ss X -i in.mkv -frames:v 1 -vf cropdetect -f null -
, где X - время кадра с черными полосами.
Ищешь в выводе строчку где написано crop=..., копируешь это, вставляешь в фильтры, Профит.
Аноним (Microsoft Windows 10: Chromium based) 22/10/22 Суб 15:21:44 3217946 340
>>3217752
Я в paint.net на скриншоте смотрю координаты для кропа.
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 01:57:39 3218924 341
К вопросу, где этот ваш av1 используется: пикабу на него переходит.
Например: https://pikabu.ru/story/passazhirka_kinula_taksista_na_1700r_9580107
Наверно, в него кодируются ролики только из самых популярных постов, как и в случае в ютюбом.
Аноним (Linux: Firefox based) 25/10/22 Втр 07:28:25 3218961 342
Мне чел в арматреде сказал что у него ав1-ств кодирует быстрее чем вп9. Ну оно, конечно, возможно, если ав1 поставить пресет 10, но всё же, при равном времени кодирования, у кого будет качество лучше?
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 17:21:18 3219060 343
>>3218924
у меня лично вп9 там открылся, не знаю где ав1.
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 19:51:16 3219094 344
1564947888903.png 570Кб, 722x1308
722x1308
1521312368035.png 31Кб, 530x622
530x622
>>3219060
Открой в mpv. Алсо, там даже в названии файла av1. Сохранил – MediaInfo показывает av1. Как ты его в vp9-то умудрился открыть?
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 21:16:05 3219114 345
image.png 28Кб, 530x622
530x622
image.png 73Кб, 1920x945
1920x945
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 21:19:47 3219115 346
Аноним (Linux: Firefox based) 25/10/22 Втр 23:23:26 3219141 347
>>3219115
> dav1d
Причём здесь твои rtx?
Аноним (Microsoft Windows 10: Chromium based) 25/10/22 Втр 23:40:56 3219148 348
>>3219115
У меня Polaris. Он не то что av1, даже vp9 не декодирует. И да, при чём здесь это?
Аноним (Microsoft Windows 10: Chromium based) 26/10/22 Срд 00:14:55 3219157 349
>>3219141
>>3219148
а вдруг сайт чекает. в яндекс браузере тоже вп9
Аноним (Google Android: Mobile Safari) 26/10/22 Срд 22:28:53 3219452 350
Какие команды записать чтобы был батник который любой видео файл конвертирует в мп4
Аноним (Microsoft Windows 10: Firefox based) 27/10/22 Чтв 04:02:06 3219506 351
>>3218961
У меня то же самое даже на пресете 5, на обычном ноутбучном процессоре. А на пресете 7 в разы быстрее libvpx-vp9, при качестве немного выше.
Вообще есть же ещё svt-vp9 какой-то...
Аноним (Microsoft Windows 10: Firefox based) 27/10/22 Чтв 04:04:06 3219507 352
>>3219452
: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

Мышкой выделяешь файлы и на батник перетаскиваешь, все строчки кроме длинной чтобы открывать несколько файлов. Но это не сработает, если у тебя несколько аудиодорожек или ещё что-то сложное в видео.
Аноним (Microsoft Windows 10: Chromium based) 27/10/22 Чтв 11:22:10 3219562 353
ap969370003938.jpg 280Кб, 3000x1887
3000x1887
>>3219507
Большое спасибо.
Кстати твоя команда даже лучше дефолтной, аж в 2 раза файл меньше весит на выходе.
Как научиться писать такие батники?
Аноним (Microsoft Windows 8: Firefox based) 27/10/22 Чтв 13:07:00 3219614 354
изображение.png 20Кб, 787x156
787x156
Аноны, подскажите.

Есть несколько чуть-чуть недокачанных видеофайлов с фильмами, в контейнере 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 моментально детектит какую-то проблему с файлом и сходит с ума?
Аноним (Microsoft Windows 10: Firefox based) 27/10/22 Чтв 14:49:40 3219659 355
>>3219614
Я заметил такое поведение в utorrent. Когда добавляю новый торрент с многосерийным сериалом, сначала ставлю приоритет файлов по порядку, от 15 (высокий) до 1 (низкий), чтобы серии скачивались по порядку от первой и так далее. Но когда торрент стартует, utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце, только после этого начинается нормальная закачка с приоритетом на первый файл как было задано.

Это специальная фича сделанная для превью, не знаю в каком конкретно софте, но по всей видимости видео так устроено, что для открытия требуется не только начало, но и конец. И это настолько известный факт, что специально запиливают в криентах такую фичу качать в первую очередь начало и конец.
Аноним (Microsoft Windows 8: Firefox based) 27/10/22 Чтв 16:31:01 3219698 356
>>3219659
>utorrent игнорирует эти приоритеты и начинает скачивть начало и конец каждого из файлов. И только когда пройдется по всем файлам и получит куски в их начале и конце
Такое со всеми файлами, включая последний файл?
Просто начало N-го файла лежит в том же куске торрента, что и конец N-1-го, так что при скачивании начала одного неминуемо скачается и конец предыдущего (кроме редких случаев, когда граница файлов совпала с границами кусков).
Аноним (Microsoft Windows 10: Firefox based) 27/10/22 Чтв 18:08:54 3219722 357
>>3219698
Да, со всеми. Я специально один раз проследил, в utorrent в списке файлов и есть и диаграмма кусков, так что видно как клиент запрашивает и скачивает граничные все подряд, и пока не закончит этот процесс нормальная загрузка не начинается.

Насчет неминуемой скачки согласен, просто такая формулировка "начало и конец" была когда случайно встретил упоминание этой фичи в интернете, и кажется для другого клиента. Просто так совпало, что заметил такое странное поведение у себя, а потом встретил упоминание как фичу.
Аноним (Microsoft Windows 10: Firefox based) 27/10/22 Чтв 18:12:33 3219723 358
>>3219722
А, насчет последнего может ты и прав, правда там как раз была озвучка, которую я исключил из загрузок, но вроде последний таки не догрузился, или по крайней мере я припоминаю что висел некоторое время незагруженный.
Аноним (Microsoft Windows 10: Chromium based) 27/10/22 Чтв 19:05:55 3219735 359
Как нормализацию сделать в webm for retards?
Аноним (Microsoft Windows 10: Chromium based) 27/10/22 Чтв 22:10:11 3219813 360
>>3219562
>аж в 2 раза файл меньше весит на выходе.
Ясен хер, там crf 30 стоит, но качество никакого не будет с ним.
Аноним (Google Android: Mobile Safari) 28/10/22 Птн 01:55:21 3219883 361
А в линуксе можно сделать скрипт на который можно было бы перетаскивать файлы или это чисто виндовая фича?
Аноним (Microsoft Windows 10: Firefox based) 28/10/22 Птн 04:35:26 3219897 362
>>3219562
>аж в 2 раза файл меньше весит на выходе.
А если 30 заменить на 40 - то будет в четыре раза меньше или типо того, и это ещё от исходного файла зависит.

Прочитать справку по ffmpeg, и справку по bat-файлам, или просто загуглить нужный тебе функционал.
Аноним (Microsoft Windows 10: Firefox based) 28/10/22 Птн 04:37:12 3219898 363
>>3219883
У меня точно такой же скрипт на питоне есть, для более сложной обработки файлов, на который можно как на батник скидывать. Я не знаю есть ли такой функционал у файлменеджера люникса - но если есть, то можно конечно, потому что питон там точно работает, а что с местными батниками (там sh-скрипты вроде бы) - я не знаю.
Аноним (Linux: Firefox based) 28/10/22 Птн 07:06:02 3219916 364
>>3219883
Я на питоне себе напердолил скрипт, который рендерит все видео, которые лежат в одной с ним папке. Не то же самое, но как вариант.
Аноним (Linux: Firefox based) 28/10/22 Птн 15:12:45 3220022 365
>>3219883
Нет. Там надо открывать консоль, ручками прописывать название скрипта, а уже потом в окно консоли скидывать сам файл, после чего запустить.
Как удалить ёбаные главы и меню навигации при конвертировании видео? Аноним (Microsoft Windows 10: Firefox based) 29/10/22 Суб 02:34:58 3220194 366
1.png 8Кб, 427x519
427x519
2.png 8Кб, 427x519
427x519
3.png 16Кб, 468x336
468x336
Конвертирую видео1 в видео2. Хочу удалить ВСЕ метаданные нахуй. Было: пикрелейтед №1.

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

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

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

-movflags disable_chpl

И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Аноним (Microsoft Windows 8: Firefox based) 29/10/22 Суб 13:34:21 3220294 369
>>3211324
С помощью винампа можно, в меню плейлиста.
Аноним (Microsoft Windows 10: Firefox based) 29/10/22 Суб 17:17:40 3220376 370
>>3220194
Может быть добавить флаг -dn? По идее там есть только аудио-видео-субтитры, и ещё некие данные, и вот -dn как раз про них. Может быть.
Аноним (Microsoft Windows 10: Chromium based) 29/10/22 Суб 17:37:30 3220392 371
>>3220250
> И это как всегда поднасрали ебаные эпплобляди со своим ебанутым нитакойкаквсе подходом.
Объясни.
Аноним (Microsoft Windows 10: Chromium based) 29/10/22 Суб 19:37:25 3220462 372
Аноним (Microsoft Windows 10: Firefox based) 29/10/22 Суб 20:23:09 3220487 373
>>3220392
Для mp4 контейнера chapters для нормальных людей хранятся в формате quicktime, а для заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись, потому что им нужно выделиться из общей массы.
Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Аноним (Linux: Firefox based) 29/10/22 Суб 21:01:10 3220502 374
>>3220487
> chapters для нормальных людей хранятся в формате quicktime
> заднеприводных выблядков с яблофонами добавили отдельные дублирующиеся Nero chapters в отдельную atom запись

Что?
Аноним (Microsoft Windows 10: Firefox based) 30/10/22 Вск 10:22:04 3220719 375
>>3220487
>Абсолютно никаких объективных причин зачем это нужно было делать не может существовать.
Может. Потому-что
>mp4
Конченый, ни на что не способный контейнер без каких-либо преимуществ, который пропихивают срыночные пердиксы из патентной параши MPEG LA и их подсосы.
Аноним (Google Android: Mobile Safari) 31/10/22 Пнд 15:35:46 3221108 376
>>3220719
Почему эпл не перейдёт на mkv тогда? Потому что они говноеды?
Аноним (Linux: Firefox based) 31/10/22 Пнд 16:57:17 3221123 377
>>3221108
Потому что это один из членов MPEG LA
Аноним (Google Android: Mobile Safari) 31/10/22 Пнд 19:00:07 3221171 378
>>3221123
Зачем повторил моё последнее предложение?
Аноним (Microsoft Windows 10: Firefox based) 02/11/22 Срд 18:34:48 3221917 379
Сап, заснял со своего шитого салями пару видосиков, а оказалось, что встроенная камера как то гробит длительность видео, но не аудио, на пикриле видеопоток длиться 59 часов, а аудио 31 секунду, сколько и должно длиться видео.
Понятное дело, любые видеоплееры охуевают от этого, и воспроизводят либо аудио, либо видео.
Ффмпега это тоже касается, он если и кодирует, то сохраняет эту длительность.
Так вот, есть ли какой то способ это исправить? Можно ли заставить ффмпег не тащить длительность видео, а составлять её самому?
Аноним (Microsoft Windows 10: Firefox based) 02/11/22 Срд 18:36:14 3221919 380
image.png 97Кб, 1920x1040
1920x1040
image.png 95Кб, 1920x1040
1920x1040
image.png 1041Кб, 1920x1040
1920x1040
Аноним (Google Android: Mobile Safari) 02/11/22 Срд 21:27:00 3221996 381
>>3221917
Ну есть один способ , но он какой-то дебильный, если кто-то знает получше подскажите
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
Аноним (Microsoft Windows 10: Firefox based) 02/11/22 Срд 21:38:35 3222002 382
>>3221996
Пасиба, добрый анон. Правда пришлось ещё видео повернуть, но это просто.
Аноним (Microsoft Windows 10: Chromium based) 07/11/22 Пнд 17:30:57 3224175 383
Все программы для конвертации так адово прессуют процессор, или это у меня майнер-эдишн?
Аноним (Microsoft Windows 10: Firefox based) 07/11/22 Пнд 19:50:27 3224238 384
>>3224175
Угу там действительно много вычислений требуется.

Есть кодеки, которые прессую карточку, а процессор уже поменьше - но они отличаются плохим качеством по соотношению размера файла к качеству изображения.
Аноним (Google Android: Firefox based) 09/11/22 Срд 02:25:57 3224697 385
ffmpeg.exe -i 123.aif -c:a alac 123.m4a
Нуб в треде. Такая команда будет идентична исходнику или нет? Мне бы в идеале распакуя обратно m4a в aif, чтоб спектр вообще был неизменным. Или все таки после этого уже не будет идентичен?
Аноним (Google Android: Mobile Safari) 09/11/22 Срд 03:16:07 3224709 386
>>3224697
В 99% неизменно, нет только если там какие-то специфичные 32 бит и подобное
Аноним (Google Android: Mobile Safari) 09/11/22 Срд 03:18:08 3224710 387
>>3224697
Можно проверить такой клмандой:
ffmpeg -i 1.aif -f hash -
ffmpeg -i 1.m4a -f hash -
Если одинаковый хеш то не изменилось
Аноним (Microsoft Windows 10: Firefox based) 10/11/22 Чтв 13:52:36 3225210 388
BogdanovBelskyU[...].jpg 313Кб, 1300x1824
1300x1824
Хочу сделать "энкод-бокс", который будет кодировать мою коллекцию старого европейского артхауса, мож ещё аниме и гачимуча порн. Плнирую кодировать через AOM. Какое железо по бомжу и одновременно мощное лучше взяь в такой бокс? Ряженку новую, ряженку старую, мож какие интолы?
Аноним (Linux: Firefox based) 10/11/22 Чтв 14:35:02 3225224 389
>>3225210
Значит так. Можешь брать сразу тредрипер, и 128 ГБ ОЗУ. Запускаешь на этом av1an, и при правильной настройке он будет загружать сразу все эти потоки, ну и молись чтобы оно не полезло в своп.
Аноним (Microsoft Windows 10: Firefox based) 10/11/22 Чтв 15:41:09 3225255 390
>>3225224
Не, ну можно конечно взяьт с алик 2*EPYC 7601, но нафига мне такая дура? По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
>av1an
Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Аноним (Linux: Firefox based) 10/11/22 Чтв 19:07:56 3225314 391
>>3225255
Ну у голого aomenc с паралелизмом дела обстоят не очень. Можно конечно врубить tiles, но это ухудшает качество.
Если ты собираешься запускать голый aomenc, то лучше новых топовых интелов не найти.
Но если тебе нужно расскрыть потенциал твоего проца на максимум, тогда тебе придётся осилить av1an. Так то что av1an, что svt оба делят видео на GOP и кодируют их параллельно.
Аноним (Linux: Firefox based) 10/11/22 Чтв 19:21:23 3225316 392
>>3225255
> По сути я хочу себе некий NAS++ который сможет более-менее эфективнго кодировать пока стоит в уголке.
Так не бывает. Тут либо файлопомойка, либо сервер нахуй.
Аноним (Microsoft Windows 10: Firefox based) 10/11/22 Чтв 22:53:40 3225407 393
TaskmgrBFJ3AMTp[...].png 98Кб, 1081x654
1081x654
>>3225314
>Ну у голого aomenc с паралелизмом дела обстоят не очень.
Действительно... С другой стороны это облегчает выбор, на нужно гнаться за многоядами. Какой-нить 11600k с рук, раскочегареный по одному ядру наверное оптимально зайдёт.
Аноним (Google Android: Mobile Safari) 11/11/22 Птн 13:05:46 3225530 394
>>3225210
Дешевле всего купить зион с большим количеством донных ядер. Конечно нормальный современный комп лучше справится
>>3225255
> Хз что это такое. По моим тестам AOM лучше работает с грэйном.
Переможный костыль для убогого кодировщика которая делит видео на множество маленьких чтоб нагрузить все ядра
Аноним (Microsoft Windows 10: Chromium based) 11/11/22 Птн 20:20:04 3225681 395
Как нормализацию сделать в webm for retards?
Аноним (Microsoft Windows 10: Firefox based) 12/11/22 Суб 04:36:07 3225780 396
>>3225681
В строчке дополнительных параметров указать нужный фильтр (их несколько вроде как) нормализации ffmpeg с нужными параметрами. То есть так же как и в чистом ffmpeg.
Никакого интерфейса для этого может и не быть
Аноним (Microsoft Windows 10: Chromium based) 12/11/22 Суб 07:24:37 3225792 397
Аноним (Microsoft Windows 10: Firefox based) 12/11/22 Суб 08:20:51 3225797 398
>>3225792
Тогда никак. Ограничение интерфейса твоей программы или просто твоей программы, она не может выполнить твою задачу.
Аноним (Microsoft Windows 10: Chromium based) 12/11/22 Суб 08:52:48 3225801 399
>>3225797
а как сделать тогда?
Аноним (Microsoft Windows 10: Firefox based) 12/11/22 Суб 12:08:08 3225821 400
>>3225801
Через другую программу.
Аноним (Microsoft Windows 10: Chromium based) 12/11/22 Суб 23:31:41 3226011 401
Аноним (Microsoft Windows 10: Chromium based) 13/11/22 Вск 09:23:14 3226095 402
13/11/22 Вск 13:43:03 3226158 403