FFmpeg и общий кодирования видео тред №14 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
12/10/25 Вск 04:32:34
№
1
В прошлый раз мы как всегда срались про кодеки, особенно про качество AV1, а после бамплимита анон разработал интересную программу.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: 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 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.su/test/ Просьба проводить тесты там, а не ИТТ.
Тред №0: https://2ch.su/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.su/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.su/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.su/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.su/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.su/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.su/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.su/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.su/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.su/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.su/s/arch/2023-12-08/res/3301315.html
Тред №11: https://2ch.su/s/arch/2024-06-09/res/3365343.html
Тред №12: https://2ch.su/s/arch/2025-06-25/res/3441805.html
Тред №13: https://2ch.su/s/res/3600915.html
https://www.opennet.ru/opennews/art.shtml?num=64033
Что ты с ним будешь делать?
Значит ли это, что битрейт надо поднимать до 30%, чтобы избежать "качества" AV1?
Вряд ли, ав1 ни на одном битрейте мыльной парашей не перестаёт быть, значит и саксесор должен эту же философию перенять.
> саксесор
Навуходоносор. Блядь. Зумереще ебаное.
Есть дохуя пикч весом от 3 до 6 мб (почти 1 тб в общем весе). Нужно осовбодить место. Нужно разом все пикчи сжать до минимального "читабельного" разрешения, т.е. чтобы весило до 1 мб, но при этом не шакальные пиксели были. И главное чтобы оригинал пикчи сразу удалялся и оставалась сжатая копия. Как сделать? Удалять не вариант. По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней. Помогите пожалуйста шарящие.
JEPG XS вроде может. JPEG XL в точный вес не может. BASH скрипт пиши.
>Сразу скажу, что регистраций во всяких нейрочатах нет, там спросить не могу
Попробуй duck.ai
>Как сделать?
Скриптами, но у тебя довольно много неизвестных ("читабельное разрешение", "не шакальные пиксели", формат пикч, ОС...), представление о которых есть только у тебя.
Там ограничения какие-то есть на кол-во запросов/время/длину беседы и т.п.?
jpegli от гугла почти как jpegxl, но в нормальном и поддерживаемым расширением везде. А не говно в .jxl
https://github.com/google/jpegli
>>3653320
> По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней.
А как ты хотел то епт?
JPEG XL, AVIF, WebP.
https://github.com/libjxl/libjxl
https://github.com/AOMediaCodec/libavif
https://developers.google.com/speed/webp/docs/precompiled
Выбери формат который тебе больше нравится и подходит, пожми для теста десяток картинок чтобы определить для себя "читабельное" качество, после чего через PowerShell пройдись по нужной папке.
JPEG XL пока не так сильно распространён и поддерживается, но он крутой. Я использую WebP, с AVIF не сильно знаком, но в некоторых случаях он вроде бы сжимает лучше WebP.
Скрипт для примера.
https://pastebin.com/raw/Jw576Lxw
Он пройдётся по всем файлам из папки "C:\Users\User\Pictures\Hatsune Miku" и перекодирует их в WebP формат с качеством "-q 85" в папку "C:\Users\User\Pictures\Hatsune Miku_Processed", при успешном перекодировании файл удаляется, структура папок сохраняется, в конце цикла удаляет папку если она пуста.
Попроси чатГПТ написать тебе бантик, который жмёт всё в папке в жпегли на дистансе ~0.5 и удаляет оригинал. Проверь на тестовой папке.
Вебп 420 кал. Авиф мыльная медленная параша. ЖпегХЛ умер нахуй, перспективы воскрешения минимальны. Из экзотики только хэйк остаётся норм вариант.
Понятно, продолжайте вести наблюдение.
Было бы за чем наблюдать...
>Авиф мыльная медленная параша
libsvtav1 очень быстрый, даже на 1 пресете.
> ЖпегХЛ умер
Он умер только в хроме. Софт его поддерживает, даже адобе. Еще недавно японцы запилили аппаратный кодировщик.
> хэйк остаётся норм вариант
Серьезно? Только яблоко его продвигает (продвигало?), и они теперь "мертвый" жрегхл поддерживают из коробки на своих устройствах.
> Он умер только в хроме
Т.е. буквально в большей части интернета
Чел приводит в пример хеик как норм вариант, хром его тоже не поддерживает.
>>3653407
Я вангую, что у хейка будет поддержка везде — на базе того что ведро с айосью его поддерживают — а с жпегXL пока влажненько выглядит, что в долгой перспективе он выживет. С хейком всё просто и понятно, тогда как XL привязан к обязательному колорменеджменту со своими наркоманскими профилями цветовых пространств. Но это гадание на кофейной гуще, конечно.
Сажа прилипла.
>>3653391
Да хуй знает, он же реально странно выглядит со своим сжиранием шумов и текстур, сколько сравнивал, всё не могу понять куда его ставить по качеству сжатия — на парашу хуже жпега или в недосягаемый остальными форматами топ. Склоняюсь к первому.
Одна строчка в каком нибудь nconvert.
nconvert -recurse -D -out webp -ratio -rflag decr -resize fill 1920 1080 *
Вот, например, рекурсивно пройдет по каталогам, все картинки конвертнет в webp, и до кучи все крупные картинки впишет в фулл ашди, оригиналы удалит.
https://wiki.x266.mov/blog/svt-av1-fourth-deep-dive-p1
https://wiki.x266.mov/blog/svt-av1-fourth-deep-dive-p2
Мне сложно сказать насколько, но обновиться определенно стоит. Плюсы - оптимизация, новые настройки и улучшения с экспериментальной версии, фиксы каких-то багов. Минусов никаких.
В гугле забанили? И в яндексе тоже?
Насколько я знаю превьюха выбирается случайным образом из начала видео и задать ее нельзя.
Гугл направил меня в этот тред, сказал что он для таких вопросов создан.
Это не так. С торрентов я качал мультики с такими картинками. Можно попробовать:
ffmpeg -i video -i audio -i mjpeg -map 0:v -map 0:a -map 1:v
где первый источник видео, второй аудио, третий картинка в mjpeg.
>>3655044
>ffmpeg -i Input.webm -i Img.png -map 0 -map 1 -c copy -c:v:1 png -disposition:v:1 attached_pic Out.mp4
Вот так. Но эта превьюшка только для системы работает, двощ все равно рандомный кадр выберет.
>>3655255
Спасибо анончики.
>двощ все равно рандомный кадр выберет
Ну это печально, как раз таки для двача хотел превьюшки ставить, а то весь смысл ролика теряется(
А почему превью этой вебм отличается на двух браузерах? В Firefox одно превью, в Edge другое.
После многочисленных жалоб на скримеры, кодеры макабы накодили так, что превьюшка генерируется из случайного кадра видоса. Видимо из-за различий в алгоритме рандомайзера, в разных браузерах генерируется разная превьюшка.
Но это чисто предположение.
>>3655717
Эти картинки на сервере макабы генерятся, поехавшие https://2ch.su/s/thumb/3652226/17608648848370s.jpg
На изображения жёсткие, если без регистрации.
Он никак не меняется, пчел. Как и ворбис. Это с тобой чот.
Я не то имел в виду. И запутал вас. У меня вопрос в другом, а именно в кадрах этой вебм-ки, почему перевязанный Сэм Лейк в Edge появляется на 7 секунде, а в Firefox уже на 3-ей?
Думаю кто-то криво слепил видео. Потому что у видео start_time с 4 секунды, а у аудио с 0.013991. Плееры вообще это видео сразу с 4 секунды запускают, обрезав часть аудио.
Вчитайся в сообщение еще раз, я не про обычный ворбис писал. И про опус не я один говорю, потому что гуглу похуй и даже в видео звук говно стал, потому что всегда через ytdlp качал 249, а щас он говно.
Ну и давно "aotuv vorbis" какие-то приросты в качестве имел? В 2008? Акстись.
То что гугол хуй пойми как жмёт, никак не влияет на доступный тебе енкодер опуса, который никак не меняется. Главная фича опуса это нулевой лэйтенси, никто не будет удивлён если его в некоторых сценариях нагнёт ворбис или аац по качеству. И вообще, опус и ворбис ориентированы на битрейты в районе 96+кбпс, ниже они будут сраться, а ты просто уши почистил и услышал шакалов.
Для экстремально низких битрейтов exhale придумали, попробуй ещё попросишь.
>Ну и давно "aotuv vorbis" какие-то приросты в качестве имел? В 2008? Акстись
Выиграл все тесты в 2023.
>То что гугол хуй пойми как жмёт, никак не влияет на доступный тебе енкодер опуса
Правки вносятся в репозиторий, а оттуда уже всем бомжам, то есть везде будет одинаково.
>Для экстремально низких битрейтов exhale придумали
Херня вообще им не пользуюсь, и поддержка хромает в хромовиках.
Test.
О! Теперь одинаково! бuджuджu
>бuджuджu
Блять, да ну нахуй, ты жив до сих пор? Я тебя уже столько раз вижу, снова зашел спустя пару лет, опять здесь!
Это подражатель, настоящий чел, который так подписывался, повесился после деанона. Витя его звали...
> ты жив до сих пор
А куда мне статься? Даже прирос в своём благополучии, приобретя в сентябре 2023 года пека за 180 тыщ., сейчас вот по классическим брендам угорел и собираю себе на костюм и пальто из ЦУМа, на гойботе повысили тоже после проведенной мной проверки предоставления учреждениями льгот СВОшникам, бuджuджu
То кодеки были какие-то ебанутые х264 10бит.
Все давно перекодируют в hevc и даже av1 всего за 150-200мб за серию, на няше достаточно поискать. Да и надо совсем древний проц иметь, чтобы x264 10бит не тянул.
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Перекодируй в srt
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - https://nyaa.land/view/1276567
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - nyaa.land/view/1276567
Не открывается ссылка.
magnet:?xt=urn:btih:84d291c384907202387314c2e6e43ea301db8fdf
Ща блять, я буду неизвестному хую палить свой айпи на двачах через ДХТ. Агабля.
Анимубляди должны страдать.
Уже придумали за тебя в виде FFmpeg Batch AV Converter в котором есть буквально всё практически. Настолько, что этот гуи можно адаптировать под exe других прог, единственный косяк постоянный параметр -i
>FFmpeg Batch AV Converter
Не хочу вайн ставить для неё, там есть функция кроп в интерфейсе? На скринах не увидел. Мне эта фича в boram нравилась, но её блядь нигде нет, чтобы было так же удобно. Ну и минус конечно, что нет нормальной сборки под линукс
>Настолько, что этот гуи можно адаптировать под exe других прог
Что это значит вообще? Зачем это?
Не понял про что ты конкретно, но есть такое
Да, типа такого, но я немного по другому сделаю
Ну так и скажи тебе хочется заняться бессмысленным ненужным пердолингом, и больше некуда время тратить. На уровне челов, который в миллионный раз пилят фронтенд для yt-dlp. В avidemux тоже кроп есть через avisynth можно прям линии ставить как тебе надо, в xvid4psp тоже есть кроп.
Мало ли что можно. Не значит что это нужно.
Сейчас анимубляди вперди всех жмут в AV1, который в моём "старом" (5 лет) телефоне железно не поддерживается. Но вроде он хотя бы существует и развивается, а не как х264 10бит мертвонерождённый.
Ну оно как минимум мне нужно, потому что boram нормально без ебли с устаревшими зависимостями не запускается, а все остальные мне не нравятся. Для себя я попердолиться не против, а там уже мне не особо важно, понадобится она кому-нибудь или нет. Ну и плюс будет какой-то опыт и проект. У меня в вузе средний проект выглядит как тудушник или календарь дней рождения
Ну короче спасибо всем за поддержку аноны, как всегда мощно обосрали
Без психической поддержки уже не может программу для себя написать?
Борам конечно дело свое делал, но это ужасающая электронопараша, даже автор уже не хочет уже разбираться в своем говнокоде.
Автор в принципе прекратил активность на гитхабе. Может быть, он умер.
https://habr.com/ru/news/965518/
Если коротко, гугл находит слишком много уязвимостей, мы не успеваем их исправлять, а гугл через 90 дней выкладывает их в открытый доступ. Дайте деняк или прекратите искать уязвимости в нашем открытом коде, ежедневно проверяемом тысячами квалифицированных экспертов, всем же известно, что в СПО не может быть так много уязвимостей.
Какие нахрен уязвимости в оффлайновой программе? Или ффмпег сообщает гуглу о том как я шебм с неграми конвертирую часами?
>Там это, ваш ffmpeg протёк
>ИИ-система нашла баг в системе декодированием кодека LucasArts Smush, в частности первых 10–20 кадров Rebel Assault 2, игры 1995 года
ffmpeg библиотеки например в хроме и фурифоксе используются, ты открываешь видео, а оно крашит твой таб или даже весь браузер, норм тебе такое?
Гугл наверняка ffmpeg еще и для перекодирования видео на ютубе использует.
Дальше что? Че то не нравится, пишите с нуля свое, делайте форк, не ебет, это опенсорс. Че-то можете предложить? Сделайте коммит.
И че они сделают, если не поправят уязвимость? Затерпят.
Вероятно это плёнка ик-фильтра начинает терять свои свойства и пропускать ик-излучение.
Почему не hevc c bframes? Хотя я свою библиотеку в av1_nvenc с cqvbr 34 кодирую с bf 7 и кучей подстроек, либо c svt-av1 он тоже достаточно быстрый.
Задача: поделить видео на части при существенной смене кадра. Есть видео, типа слайдшоу, с переменной длиной слайдов. Нужно порезать это видео по слайдам. Но картинка на каждом слайде статичная не полностью, примерно 80% экрана остаются неизменными. Общая длина видео - чуть больше десяти часов, количество слайдов - примерно тысяча. Руками это будет адски долго и мучительно делать.
Пока на ум приходит только вытащить фреймы, и найти таймкоды изменений сторонними решениями (можно и самому скрипт написать, несложно). Но это костыльно - сохранять больше двух миллионов фреймов как отдельные картинки. Для raw не хватит места, а жать каждый фрейм - сколько времени уйдёт на одно только это, и ведь потом их ещё перебирать.
Может есть более адекватное решение?
ffmpeg divide video when scene change
Как с lossless AV1 совместить AAC аудиодорожку из M4A и PNG пикчу в MP4? Цвета проёбываются, пикча вся ядерно-зелёная. Конкретно прописывать rgb24 пробовал.
Stream #0:0: Video: png, rgb24(pc, gbr/bt709/iec61966-2-1), 1280x576 [SAR 3779:3779 DAR 20:9], 25 fps, 25 tbr, 25 tbn
-c:v libaom-av1 -aom-params lossless=1
С libx265/4 просто крашит при проигрывании везде на телефоне, на ПК не пробовал.
ffmpeg.exe -i videvo.mkv -i audivo.mka -i piccha.png -map 0 -map 1 -map 2 -c copy govno.mkv
>>3669707
>>3669708
Не понял реквест. Тебе нужно видео из статичной картинки в 1 FPS + звуковой дорожки в ААС, взятую из М4А файла без перекодирования?
Либо как написали ffmpeg нарезка по scene changes, threshhold выставлять можно вручную. Для scene changes также есть скрипты на питоне. Либо если просто вес видео снизить или чтото подобное до deduplication frame сделать.
Кодировать в 4:4:4 или 4:2:2
С подходящими, блядь. -b:v 850k и иди нахуй.
Ты чего грубый-то такой, епта. Как будто я каждый день этой хуетой пользуюсь. Сейчас попробую, спасибо.
-c:a copy можешь попробовать добавить. Не факт что сработает, смотря какое аудио в mov.
В два раза с небольшим сжал, аудио-визуально норм. Для аудио сделал бегающий битрейт, получилось еще немножко дожать. Спасибо.
>ffmpeg -i Input.mov -pix_fmt yuv420p10le -c:v libsvtav1 -preset 4 -crf 35 -svtav1-params tune=0:keyint=480:qp-scale-compress-strength=3:enable-qm=1:qm-min=0:qm-max=8 -c:a libopus -b:a 64k TMP.mp4
Пресет можешь выставить 2, будет немного качественнее, но ощутимо медленнее.
Keyint я ставлю х20 от частоты кадров, можно выставить х10 ради чуть более быстрой перемотки.
CRF надо подбирать, чем больше тем компактнее, но ниже качество. Я подбираю на быстром пресете 10, можно примерно почувствовать каким будет битрейт на тех же настройках на более медленном пресете.
В svt-av1 10bit crf 32-36, preset 4-6.
Вот можно скачать видео yt-dlp, с результатом все в порядке, можно продолжить скачивание с момента прерывания, но: более медленное скачивание и постфиксинг удваивает использование диска.
Я нагуглил способ качать ффмпегом -
ffmpeg -protocol_whitelist file,http,https,tcp,tls,crypto -ss 00:00:00.00 -i "ссылка" -to 60:02:00.00 -c copy имя.mp4
Если скачивание оборвалось, то только заново начинать или делать отдельный файл с момента обрыва. Но такое редко бывает.
Но есть постоянный раздражающий момент: не скачиваются первые где-то 2 секунды или даже со 2 секунды скачан звук, а видео только с 5 появляется.
Можно что-то поправить, чтобы скачивание было с самого начала?
Хуй знает что ты качаешь, хуй знает что ты качаешь, хуй знает что ты качаешь. Ещё отрезаешь там чего-то.
Скачивание не медленное. С хуя ли оно медленное? Через один и тот же интернет качает. Можно сразу несколько частей параллельно качать.
Можно отключить постфикс в ют-длп. Надо только прочитать редме.
Я когда-то вообще качал партсы через загрузчик и потом слепливал их ффмпегом.
А можно что б ют-длп не удалял скачанные партсы, тогда потом он сможет подхватить старые партсы и качать новые, надо только промежуточное и готовое видео удалить (если оно появилось).
Я один люблю аутировать пережимая всякую медиа хуйню?
Да. Абучан не принимает M4A.
FFprobe на файл лучше кидай.
Ну вот такой батник попробуй:
ffmpeg -i Input.m4a -vn -c:a copy TMP.aac
ffmpeg -framerate 1/X -i Img.png -i TMP.aac -c:v libx264 -r 1 -c:a copy Out.mp4
del TMP.aac
Вместо X во второй строке длительность аудио в секундах.
> Хуй знает что ты качаешь, хуй знает что ты качаешь, хуй знает что ты качаешь. Ещё отрезаешь там чего-то.
Воды с кика и твича. Про отрезание я ничего не писал.
> Скачивание не медленное. С хуя ли оно медленное?
Не медленное, а медленнее чем ффмпегом. На винде разница вроде небольшая, я даже не приглядывался. А вот на лине скорость скачивания у ффмпег команды оказалась в 1.5 выше чем на винде и теперь разница с yt-dlp, где скорость осталась такой же, стала большой, где-то x2. Только я не
> Можно сразу несколько частей параллельно качать
а просто "yt-dlp разрешение ссылка" делаю, там последовательное скачивание, может параллельно кусками будет супер быстро, но я не умею, а мне и так норм.
> Можно отключить постфикс в ют-длп
Сырой файл заметно больше постфиксного и у него нет метаданных или их части.
> А можно что б ют-длп не удалял скачанные партсы, тогда потом он сможет подхватить старые партсы и качать новые, надо только промежуточное и готовое видео удалить (если оно появилось).
Ну я про это и писал, только скачивая последовательно будет один парт он же промежуточный, просто к нему дальше будет прилепляться.
Это делается гораздо проще.
ffmpeg -loop 1 -framerate 1 -i img.png -i aud.mp4 -map 0:v:0 -map 1:a:0 -c:v libx264 -pix_fmt yuv420p -c:a copy -shortest outname.mp4
-map нужно если вместо непосредственно аудио-файла подсовывать видео-файл с аудио дорожкой с отбрасыванием самого видео, но в таком случае надо следить чтобы аудио в видосе было aac.
Тому шо там хуета какя-то а не гайд. Надо сделать лучше, но всем лень.
Потому что ты древнее говно десяти лет откуда-то откапал.
Вышел AV1. VP8 и VP9 больше не актуальны.
У меня AV1 на процессоре обрабатывает 5 минутное видео 100 лет через libaom-av1, а видеокарта не поддерживает его, только декодирование.
libaom ее тоже потерял никогда и не был актуален из-за скорости кодирования с выходом оптимизированного SVT-AV1.
>SVT-AV1
libsvtav1 в ffmeg, увидел, затестил, охуенный. Спасибо за информацию, быстро перекодировал и по размеру видео лучше намного.
Не нужно.
>на выходе получается каша с нечитаемыми словами
Ты бы показал что получается и написал как кодировал.
Уже поздно, дня через три, может четыре напишу.
Перегруженное говно устаревшее.
Согласен на андрюше своем кодирую видео через termux прям огромное счастье, скорость даже на 778g на пресетах 2-4, которые использую на пк изумительная. Выходит около 8-12 фпс в сек.
ffmpeg -i -c:v libsvtav1 -crf 32 -preset 4 -g 120 -pix_fmt yuv420p10le -vf scale=-1:720:sws_flags=lanczos -svtav1-params tune=0:film-grain=8 -c:a libopus -ab 80k -ar 48000
>libsvtav1 в ffmpeg, увидел, затестил, охуенный
>Перегруженное говно устаревшее.
>и что использовать?
>-c:v libsvtav1
Это лыжи не едут, или я долбаеб?
Ты посты путаешь как будто. Перегружен гайд и написан всрато, плюс кодеки там древние. Про svtav1 ни слова, бтв есть даже лучше форки чем svt-av1, надо искать на дискорд каналах. SVT-AV1-HDR
А, да, у меня почему то не тот пост отобразился, на который ты ответил.
Прочитай информацию в том репозитории, откуда скачиваешь.
В консоль при запуске выводится информация о конфигурации, запусти два разных и посмотри разницу.
>должен весить
Нет какой-то твердой цифры, ты (или автор билда) при сборке задаешь набор библиотек которые войдут в билд. Я вот этот беру.
https://github.com/AnimMouse/ffmpeg-autobuild/releases
>>3677158
А есть какойто совсем маленький и компактный? Мне ток мп3 в вав массконвертить для одного bash скрипта надо.
Я не знаю, но думаю такое только самому собирать.
А если версии 10-20 летней давности? Или там другие команды уже?
Ну попробуй найди. В чем собственно проблема? Разве 110 Мб это так много?
Есть версия с вшитыми либами в каждый экзешник, а есть версия где либы отдельно от экзешников.
>Мне ток мп3 в вав массконвертить
Возьми какую нибудь lame и не ипи моск.
Моя сборка весит 47М, 20М после upx.
Если вырезать всё, кроме аудио, то будет намного меньше.
Но проще взять lame, как выше посоветовали.
Где такую версию надыбать?
>>3677425
>>3677438
А не пашет lame в баш скрипте, как только не крутил, хз почему. Скрипт правда нейронка писала. Но вот ффмпег пашет натолично. Я коверчу из мп3 в огг, ужимая сильнее, а огг с мп3 напрямую не дружит, ему вавку подавай.
Можно попробовать что-нибудь вроде
lame --decode --mp3input -t - - | oggenc -r --ignorelength -o output.ogg -
Нашел на диске версию ffmpeg, которая весит всего 151 кб. В папке аирдроида была. Справляется с конвертом в вавку наотлично, а большего от нее и не надо.
Вот это же быстро и без артефактов?
Я так через жопу собираю видео. Сначала нарезаю кусочки вот таким образом, потом склеиваю их все вместе и уже кодирую со сжатием.
Скорее всего это версия без встроеных либ, а либы откуда то из path подхватываются. Так что это по сути тот же тяжеловесный комбайн.
pcm_s16le заменить на flac или alac похуй. Иначе мп4 глючит.
Поскольку каждый человек слышит по своему, то вместо использования своей необъективной психоакустики, сделал программу, которая сравнивает два wav-файла и выдает среднюю разность уровней семплов (попугаи). Чем попугаев меньше, тем лучше.
Как оказалось, последний кодек lame режет верхние частоты, что никуда не годится. Нашел что кодек lame 3.93.1 может не резать верхние частоты по ключу -k.
Дальше начал эксперименты с основными параметрами кодирования и определил лучшие: -mj -b320 -q0 -k
В кодеке есть еще куча дополнительных параметров тонкой настройки, но я в них не ковырялся. Наверное возможно сделать лучше.
На скринах спектры оригинала и кодированных с параметрами -mj -b320 -q0 -k в lame 3.93.1 (136 попугаев) и в lame 3.100.1 (233 попугаев).
Трек выбрал потяжелее (Rammstein - Deutschland), чтобы было видно больше артефактов кодирования на спектрах. В менее тяжелых треках спектр у lame 3.93.1 может совсем мало отличаться от оригинала.
>Как оказалось, последний кодек lame режет верхние частоты, что никуда не годится. Нашел что кодек lame 3.93.1 может не резать верхние частоты
Разве это не common knowledge еще с середины нулевых?
>и определил лучшие: -mj
Хз, обычно раньше на жоинт стерео плевались и строго в -m s кодировали.
>обычно раньше на жоинт стерео плевались и строго в -m s кодировали
C -ms на cbr чуть больше попугаев показывает. Значит жоинт стерео высвобождает битрейт на более качественное кодирование.
>Разве это не common knowledge еще с середины нулевых?
Наверное. Жаль что сейчас все форматы режут верхние частоты, оправдывая это тем что они не слышны человеком. Но по моему все равно косвенное воздействие этих частот человек чувствует. Не надо их срезать.
Люди не слышат частоты выше 20к - это идеальный максимум который к тому же не у каждого может быть, а чувствительность сильнее всего в детском возрасте и со временем она только падает. Кодировать частоты выше этого уровня бессмысленно в любом случае и это лишь расходует ресурсы на бесполезные и ненужные частоты которые режут все лосси кодеки даже с максимальным битрейтом.
Mp3, а конкретно lame, всё это время развивался и свежие версии на тех же самых битрейтах гораздо качественнее старых, тем более 2002 года, не говоря уже о том что сам по себе mp3 уже давно устарел - есть AAC и opus.
>Но по моему все равно косвенное воздействие этих частот человек чувствует
В интернете куча abx тестов не чувствуют этого.
Эх, вот бы мне не слышать писк от электроники.
Видеокарта, мышка, монитор, даже посудомойка, всё пищит.
Так они пищат на 5-10 кгц. Скачай на телефон какой-нибудь анализатор звука и посмотри. Очень удобная штука.
Ещё можешь скачать генератор и послушать до сколько килогерц ты слышишь.
Если устройство воспроизводит высокие частоты, то они же физически есть, а значит влияют на кожу, на тело в целом. Пусть их напрямую не слышит слух, но они добавляют настоящести. К тому же есть биения близких частот, что придает окрас слышимому звуку, улучшает атаку.
> Так они пищат на 5-10 кгц.
Печально.
> Ещё можешь скачать генератор и послушать до сколько килогерц ты слышишь.
16.1K едва слышу.
https://www.szynalski.com/tone-generator/
>Кодировать частоты выше этого уровня бессмысленно в любом случае и это лишь расходует ресурсы на бесполезные и ненужные частоты которые режут все лосси кодеки даже с максимальным битрейтом.
Форматом заявлено что он поддерживает такую то частоту дискретизации, а по факту там меньше. Получается наебалово. Можно же было оставить все частоты, но много битрейта на неслышимые частоты не расходовать, так чут чут. Или хотя бы дать возможность выбора при кодировании, фильтровать или нет.
>Mp3, а конкретно lame, всё это время развивался и свежие версии на тех же самых битрейтах гораздо качественнее старых, тем более 2002 года
Я сравнивал lame 3.93.1 и в lame 3.100.1 на треках без высоких частот - lame 3.93.1 показал меньше попугаев, а значит он более качественный.
Единственное, что ты смог показать, это свое скудоумие.
>>3677775
Не забудьте только что ещё бразуер, ось, звуковуха и динамики тоже оптимизированы под человеческий слух и тоже далеко не весь диапазон передают.
ffmpeg.dll есть в папке аирдроида, но весит она тоже немного - 3 мб.
то есть надо например создать видео из статичной картинки и аудио, надо всё равно прописывать -framerate 2
пример с которым создал видрил
ffmpeg -loop 1 -framerate 2 -i image.jpg -i audio.m4a -c:v libx264 -tune stillimage -pix_fmt yuv420p -vf "scale='iw-mod(iw,2)':'ih-mod(ih,2)'" -preset placebo -crf 30 -c:a copy -shortest -movflags +faststart output2.mp4
Все что я делал в 1 фпс из картинки нормально постилось и воспроизводилось. Не знаю о чем ты.
includeadb - у меня нет этих файлов в папке. И эксешних 100кбайтовый работает отдельно без проблем, безо всяких длл конвертит из мп3 в вав.
Можешь команду скинуть, у меня почему то не всегда работает. Или попробуй в моей 2 на 1 заменить. Хз может дело в чем то другом
видимо дело в отсутствии -movflags +faststart
я ожидал что сразу воспроизведётся а надо ждать пока всё прогрузится
А нет, дело в аудио. с m4a не работает превью а с aac да. если надо с m4a надо ставить framerate 2.
И размер коллекции вышел в 5 раз меньше, чем был, с незначительной потерей качества. Как же av1 ебет.
Можете пожалуйста прислать используемые вами команды?
Эм, я в хмедиа ковертил.
Кста при пережатии порнухи у меня больше разница выходит - до 10-20 раз меньше размер. Само собой по большей части из-за статичного фона в большинстве порнухи, а ав1 умеет сильно на этом экономить. Но и пережимаю все в 720р, но квантайзер выше делаю - 43.
пережми видрил
Ну вот тут да. У меня тоже несколько попалось, которые не ужимались или даже больше становились. Ну такие я фильтрую и оставляю старую мп4. Ну можно еще попариться и уменьшить фпс и разрешение.
Ой, чет тупанул и не с той папки файл автоматом вкинул. Норм ужалась она.
хм, а я shutter encoder использую, про эту прогу не знал, попробую может она лучше
--------> >>3670201
>>3678172
Тут видно что видео уже сильно зашакалено. Ужать еще можно, но не на CRF 43 и это только добавит новых артефактов.
У тебя звук в говно превратился.
Для архива сгодится. А если не найдешь оригинал, то нейросетка восстановит.
Я на 50 сжимал, и у меня вышло больше. А ты как при 43 ужал?
Сжал в ав1. Чуете разницу? Чуете?
https://files.scene.org/view/demos/groups/farb-rausch/fr-030_candytron_final.zip
Чую. Мыльных шакалов много вылезло.
>А ты как при 43 ужал?
Никак, это был CRF 50.
>у меня вышло больше
Я длину GoP на 15 секунд выставил.
попробовал ещё раз, вроде качество примерно то же, но поменьше на ~90 кб
вот использованные команды если что
ffmpeg -i test.mp4 -vf "mpdecimate,hqdn3d=1.5:1.5:6:6,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=10:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=4:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=960:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z.mp4
дальше только стоит менять variance-boost-strength=(2/3/4)
enable-qm=1:qm-min=(5/10)
nlmeans, ну и crf
в остальном всё равно придётся менять разрешение и аудио, дальше либо слишком долго ждать либо уже картинка кукольной будет
забыл добавить
ffmpeg -i test.mp4 -vf "mpdecimate,nlmeans=s=5.0:p=9:r=21,format=yuv420p10le" -color_range tv -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:v libsvtav1 -preset 0 -crf 48 -svtav1-params tune=0:enable-qm=1:qm-min=5:qm-max=15:aq-mode=2:enable-variance-boost=1:variance-boost-strength=3:film-grain=15:film-grain-denoise=1:enable-overlays=1:enable-cdef=1:qp-scale-compress-strength=3:sharpness=0:enable-tf=1:scd=1:lookahead=120:keyint=10s:pred-struct=2 -c:a copy -frame_duration 60 -movflags +faststart -fps_mode vfr z1.mp4
>enable-overlays=1
>enable-variance-boost=1:variance-boost-strength=3
Ухудшает компрессию.
>aq-mode=2
>sharpness=0
>enable-cdef=1
>enable-tf=1
>pred-struct=2
Дефолтные значения, указывать не обязательно.
>scd=1
Не работает.
>lookahead=120
Не работает в режиме CRF (правда тестил я еще до выхода 3.х.х).
Скачал аудиокнигу, она в формате нескольких mp3 файлов
Пытался спросить у нейродебила как их объединить в m4b, на что он дал такую команду
>ffmpeg -f concat -safe 0 -i mylist.txt -c copy book.m4b
На что ffmpeg мне выдал ошибки
>Could not find tag for codec mp3 in stream #0, codec not currently supported in container
>Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Дальше нейродебил начал нести чушь
Как конвертнуть? mp3 конвертнуть во что-то другое?
я пытался баланс найти между качеством и сжатием. естественно если надо совсем в нулину сжать можно кое что убрать но тогда и субьективно качество чуть похуже будет
а lookahead всё равно влияет на расрпеделение квантователя внутри кадров хотя на нулевом пресете и так большое окно анализа
Для копирования в конкате нужен тот же самый кодек на выход с одинаковыми параметрами вроде битрейта у входных файлов.
Либо ffmpeg -f concat -safe 0 -i mylist.txt -c copy book.mp3 то есть на выходе будет mp3
Либо реэнкодить в aac: ffmpeg -f concat -safe 0 -i mylist.txt -c:a aac book.m4b
>баланс найти между качеством и сжатием
О том и речь. enable-overlays и enable-variance-boost улучшают качество, но за счет прироста битрейта. Если вместо этих опций поднять битрейт до того же значения через повышение qm-min/qm-max или снижение crf оценка VMAF будет немного выше.
>а lookahead всё равно влияет
Я выставлял 24, 72, 120, вообще убирал - на выходе получались одинаковые файлы, до байта. Как будто на CRF он его игнорирует.
Вот на VBR небольшое влияние было.
> ffmpeg -f concat -safe 0 -i mylist.txt -c:a aac book.m4b
Это пробовал, другая ошибка была
Получилось просто mp3 -> m4a все конвертнуть и их потом в m4b
Осталось придумать как бы на главы разбить все это дело
А почему так? Нах вп9 нужен? Могли бы освободить мощностей (и места бы больше было) для ав1, и пресет получше выставить. Зачем они это делают?
VP9 потому что аппаратное декодирование AV1 есть еще не у всех. Кодируют 360р как попало скорее всего потому что в таком качестве почти никто не смотрит.
Каким был исходник мы не знаем. Ну и выдергивать статичные кадры из динамичной сцены, да еще и длительностью в 0.65 секунды абсолютно бессмысленно.
Потому что цель не слепое следование хайпу как у местой ав1-лахты, а вариативность чтобы как можно больше пользователей имело доступ к контенту.
>Кодируют 360р как попало скорее всего потому что в таком качестве почти никто не смотрит.
Там такая же каша и в более высоких разрешениях. И в 1080p, только чуть менее заметная.
>Ну и выдергивать статичные кадры из динамичной сцены, да еще и длительностью в 0.65 секунды абсолютно бессмысленно.
Ага, настолько бессысленно, что аж в комментах под этим трейлером многие были настолько в ахуе от качества сжатия, что не поленились об этом отписать. Наверно в 144p смотрели, ага!
Эм, а как вп9 в этом помогает? Для остальных хватит и h264. Какая то тупость нереальная. Разве не так?
360 очень много смотрят на маленьких экранах, в режимах картинки-в-картинки и всяких автоплейных карточках которые они суют не спрашивая.
Но кодировать там можно на отъебись, это так.
>>3679182
Тоже не, H.264 жирный. И сейчас уже есть клиенты которые H.264 не умеют, а VP9 умеют. Линуксы красноглазые в основном, но и аппаратные платформы встречаются.
Тут не какая-то бинарная задачка что одно лучше чем другое, а сложные поиски баланса между зрителями, траффиком, хранилищем и процессорным временем.
Но сейчас все чешут репу что делать с тремя кодеками в переходном состоянии, вполне вероятно что мы скоро придём либо к паре AV1+H.264, либо AV1+VP9, а третий помрёт. и начнём чесать репу что делать с H.266, AV2 и AVS3
У ВК Видео доклад был недавно. Видео вроде нет публично, но презентацию можешь полистать: https://vtconf.com/talks/7658d5759967410aa3def6cea5e00434/ там VP9 гасят по чуть-чуть например.
>Например фильм 1.5-2 часа вжать в 40 мегов двача.
Разрешение по любому придется понижать, звук в моно 8-10к.
Если делать через VBR (120 минут в 40 Мб это примерно 45.5kbs на видео + звук) то как-то так:
>ffmpeg -i Input.mp4 -vf "scale=768:432" -pix_fmt yuv420p10le -c:v libsvtav1 -preset 2 -с:b 38k -svtav1-params tune=0:keyint=480:qp-scale-compress-strength=3:enable-qm=1:qm-min=0:qm-max=8:enable-dlf=2 -ac 1 -c:a libopus -b:a 8k TMP.mp4
Надо учитывать что однопроходный VBR недодаст битрейта, а в два прохода ffmpeg не умеет. Плюс CRF выдает немного лучшее качество в том же битрейте и несколько быстрее.
Если делать через CRF то -с:b 38k заменяется на -crf 60 - но тут проблема в том что выходной битрейт зависит от контента и ты можешь как сильно недобрать, так и перебрать. Факап.
Поэтому придется разбивать (достаточно таймкоды определить) фильм на десяток кусков по 10-15 минут (в идеале по смене сцены), и кодировать их по отдельности подгоняя crf в большую или меньшую стороны. А потом склеить куски через -concat. Врядли ты готов так заморачиваться ради того чтобы понтануться на двоще.
В любом случае качество видео и звука будет помойным, а время кодирования измеряться десятками/сотнями минут.
Благодарю.
>Врядли ты готов так заморачиваться ради того чтобы понтануться на двоще.
Да, наверное не стоит, все равно такие шакалы смотреть никто не выдержит.
Примерно так. Вполне смотрибельно на небльшом экранчике. Это ж сколько фильмов можно на 1 двд запихать, вы только вдумайтесь! ~126 фильмов Вся коллекция человечества лучших фильмов влезет уже на десяток двд! Вдумайтесь какая экономия. А мелкие детали мозг дорисует, или нейросетка в будущем.
А с ав2 еще пиздаче будет.
>Разве это не common knowledge еще с середины нулевых?
Там еще помимо этого в mp3 старый баг с добавлением пустоты в начале файла вроде. Хз зачем нужен mp3 в 2026.
Я так порнушку на телефоне перекодировал, фотки видео мемы и размер уменьшился на 40 гигов. av1+jpegli ебет.
>>3678170
>>3678172
В дерьмовом режиме, еще и cq 50 кодируешь поэтому у тебя говно выходит. Звук тоже хуевый.
А как надо? Я же батчем фигачу, там сотни видосиков.
И на качество звука мне насрать, речь понятна - более чем достаточно.
VBR вместо CBR. Если ставишь низкий битрейт (24k это уже низкий) лучше в моно кодировать, по ощущениям так меньше искажений.
>зачем нужен mp3 в 2026
Для всякой древноты и просто олдскула.
Двухпроход crf 38 максимум, preset 4 сойдет, еще быстрей то 6.
Фу. Все обрезано выше 20 кГц.
исходник из flac перевёл в vbr opus 192кб, (12.3мб)
ну и склеил с обложкой чтобы видео получилось (12.7мб)
ffmpeg -loop 1 -framerate 1 -i сщмук.jpg -i output.opus -c:v libx265 -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidria.mp4
по тестам libx265 именно когда статичный кадр всегда весит меньше при прочих равных, даже меньше av1. можно ещё ужать? или только crf занижать? а он и так низкий
С видео вообще ничего делать не нужно, у тебя там и так битрейт 3k. А вот использование HEVC нежелательно, у части пользователей не воспроизвелется в браузере. Используйуй AVC.
Звук можно ужимать до 96-128k, разницу с 192k все равно никто не услышит.
>разницу с 192k все равно никто не услышит
я услышу. 192 это более менее прозрачный звук при переводе из flac. (так и храню муз архив на пк)
понижаю битрейт только если не укладываюсь в 40 мб
Патлатый безкислородный балалечник, опять ты? Когда альбом-то уже блять?
Что? Хз о чём / ком ты.
Ну раз для себя - оставляй как нравится. Но с видео заморачиваться смысла нет, это пара процентов от общего битрейта.
да вот только почему то видео avc на дваче не работает (локально всё ок) с framerate 1 если аудио не aac. приходится ставить framerate 2 если аудио opus/m4a что веса накидывает.
ffmpeg -loop 1 -framerate 1 -i image.jpg -i audio.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p10le -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart output.mp4
поэтому то я и использую HEVC
сам попробуй. ну или это я что то не так делаю.
Видео что я скинул выше - AVC в 1fps + Opus. И оно, и все остальные что я делал работают без проблем.
ну вот посмотри
вот такая шляпа.
скинь какие команды юзал пожалуйста
> Stream #0:0[0x1](und): Video: h264 (High 10) (avc1 / 0x31637661), yuv420p10le(pc, bt470bg/unknown/unknown, progressive), 700x700 [SAR 1:1 DAR 1:1], 5 kb/s, 1 fps, 1 tbr, 16384 tbn (default)
Избавься от 10 бит для начала.
У меня кстати нормально показывается.
Проверил скрипт. Генерирует картинку в sox и делает webm (av1+opus).
>>3681264
Оригинальный файл с YouTube Music. Бывает хуже. А вот это mp3.
хмм, надо же магия, и правда дело было в битах.
всего то yuv420 а не yuv420p10le и всё заработало, спасибо.
хотя вес всё равно побольше hevc, но похоже это цена за совместимость
ffmpeg -loop 1 -framerate 1 -i cover.jpg -i output5.opus -c:v libx264 -tune stillimage -pix_fmt yuv420p -preset placebo -crf 45 -g 150 -c:a copy -shortest -movflags +faststart hidrian8+9-264.mp4
>-preset placebo
Если поменять на veryfast сколько будет весить?
поменьше 25.5 мб вместо 25.8 на placebo, но и картинка чуть пошакальнее, хотя на таком crf в статике значения особо нет
Летучая мышь в треде, все в пещеры!
Или посложнее функции. t2, например
Спасибо что продолжаешь веселить тред своими скудоумием и некомпетентностью.
>VBR вместо CBR.
C vbr больше размер выходит.
>crf 38 максимум
Жирновато выходит! Я эти ролики то смотрю раз с 10 лет, чисто в архив и пох.
>раз с 10 лет
легче удалить или на облако залить
Не легче, история как никак. И надо хранить, чтобы не забыть.
Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Не видел такой щедрости в нашем мухосранске.
Говорят сейчас можно заказать что угодно откуда угодно. Пиздят наверно.
Возможно не туда пишу. Хочу скачать вот https://www.youtube.com/watch?v=_bQ_u5mKLko это видео - но у него ограничение по возрасту стоит, ничего не помогает. Может кто-нибудь из вас его скачать и в тред в виде webm закинуть?
> Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Шутишь?
Так ты не 1тб смотри, а минимум 4тб, там по 3к за 1тб. Если ты бохатый, то нормально. Если не бохатый, то милости прошу на авиту, бери вилку и чисти. Моё личное мнение, лучше два б/у диска с авиты чем один новый из магазина.
И придет говно нерабочее, дальше что?
Это значит что ты лох. Выбирай лучше. Я выбирал, покупал, нормально пришло.
Телепатией выбирать? А если посылку как джим керри доставят и продаван будет не при чем?
https://x.com/videolan/status/2009025832187252874
Энкодер, который они использовали:
https://gitlab.com/AOMediaCodec/avm
Лучший кодек, работайте, братья.
Должно быть реально. Попробуй принудительно установить точную длину источника:
ffmpeg -i видео -i источник_аудио -to 00:11:22.500
Загружаю в рипер видос в формате mp4, скорость потока 2377 кб/с.
Редактирую
Рендерю в mp4. Разрешение оставляю оригинальное, качество выставляю 2500 кб/с - на выходе картинка какая-то зашакаленная по сравнению с оригиналом - словно глубина цвета меньше и картинка местами едва заметными квадратиками идёт.
Пробовал выставлять качество потока 5000, менять контейнер с h.264 на mpeg2, менять resample mode - никакого толка.
ЧЯДНТ?
> Как рендерить без потери качества?
Копировать и вставлять.
Кодируешь видео как угодно, потом копируешь звуковой поток с этого видео и видеопоток с исходника в конечный файл.
Это не ответ на вопрос братан. Либо я тебя не понимаю.
На том скрине что ты приложил я не вижу нужных тебе настроек. Есть выпадающий список options, поищи там что-то вроде -c:v copy, -qp 0 или lossless=1. Если нет значит скорее всего никак, скачай ffmpeg и просто копируй видеопоток с исходника.
>Есть выпадающий список options, поищи там что-то вроде -c:v copy, -qp 0 или lossless=1.
Ща попробую, спасибо
>просто копируй видеопоток с исходника.
>-c:v copy
Помогло, братиш, спасибо.
> 2fsiqa
Что за метрика такая? Откуда пик?
Я сейчас режу видео и кодирую части супербыстро без потерь, а потом собираю все части вместе и кодирую их уже с потерями.
Красивыми видеоредакторами я так и не научился пользоваться.
Ставь -ss перед -i. Будет выбирать ключевые кадры.
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
Неожиданно, что heic там побеждает, с другой стороны, там свой особенный датасет и своя метрика, пусть даже и построенная на существующих признанных.
В основном этот выигрыш за счёт того что хэйк смог в 12 битные файлы, тогда как авиф почему-то обосрался выше 10 бит подняться. Плюс у хейка "complexity=100" слоупочное, наверное, что-то дополнительно смогло выиграть. А может просто реализация в libheif лучше, чем в libavif и надо было ей и авиф сжимать. Много чего может быть, так-то они практически одинаковые, близкая к погрешности разница.
Меня больше результат жпег-хл удивил.
Видео с моего телефона сасунг.
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.mp4"
ffmpeg.exe -i "xxx.mp4" -ss 24:34 -to 25:47 -c copy "xxx.mp4"
В первом случае вроде должен резать по ключевым, но режет точно там где указано. Может быть остаётся невидимый огрызок до начала видео? Как проверить? Попробовал сдвинуть ss на 24:33.5 и получил точно такой же размер файла до байта, на время на 0,5 секунды длиннее.WinMerge показал что файлы почти совсем полностью одинаковые, только несколько байт отличаются. Вот такое наебалово! При склейке через concat file 'xxx.mp4' тоже хуйня получается, дёргается в местах склейки.
Во втором случае режет по следующему ключевому, первые пол секунды отсутствуют.
То есть режет либо до, оставляя невидимое начало, либо после, оставляя отсутствие кадров. Вертел на хую такие фокусы. Лучше буду резать в супер-быстро без-потерь и кодировать при склеивании.
А вот если писать
ffmpeg.exe -ss 24:34 -to 25:47 -i "xxx.mp4" -c copy "xxx.ts"
То режет до и не скрывает начало. И потом конкатом можно объединить в мп4 и ничего не глючит и не дёргается.
С мкв кстати тоже так же работает. Ну ок. Значит проблема была в том что я копировал стримы в мп4.
А как ты написал
ffmpeg -ss 15 -i video.mkv -to 33 -c copy video_copy.mkv
Лучше вообще не писать. Если писать -ss до -i, то -to после -i отсчитывает время в уже укороченном видео. Это вводит в заблуждение. Лучше тогда писать -t.
Мне кажется я изучаю какую-то хуйню уже давно разжёванную и описанную, но нигде не вижу где это прочитать.
Так у тебя транспортный стрим, попробуй сначала превратить его в обычный файл копированием всего (без попыток что-то отрезать) и только потом резать файл по ключевым кадрам.
Чего? Мп4 это транспортный стрим? Или х265 это транспортный стрим?
У меня мп4 файл с телефона самсунг, внутри х265 и аац. Во что ты хочешь его там превратить?
> Мне кажется я изучаю какую-то хуйню уже давно разжёванную и описанную, но нигде не вижу где это прочитать.
Для таких монтажёров, как мы, которые
> Красивыми видеоредакторами так и не научились пользоваться
Сделали AviSynth и VapourSynth.
Рекомендую использовать с https://github.com/vapoursynth/bestsource/releases
Про стрим ты сам написал и подчеркнул, что вот с расширением ts то всё работает. Когда ты получаешь некий стрим по UDP, неважно в каком формате, целостность файла не гарантируется, там пропуски могут быть, а ты его ещё и резать пытаешься по ключевым кадрам.
Я про стрим ничего не писал. Я просто видео на телефон снял, скопировал на компуктер и режу его.
>Меня больше результат жпег-хл удивил.
Попробовал с его параметрами avif vs jxl на этих датасетах:
https://imagecompression.info/test_images/ (RGB 16 bit)
https://people.xiph.org/~xiphmont/demo/daala/update1files/
Считал только ssimulacra2, jxl значительно лучше жмет на rgb 16, на daala разницы почти нет.
По этому 16 битному тесту у меня тоже выходит, что JXL лучше сжимает, хз даже. Маловато пикч в нём, но тут надо подбирать другую скорость, чтобы можно было потестить на большем количестве хайрезных фоток...
Очевидный минус этого датасета, что мы измеряем насколько хорошо они справляются с сохранением исошумов по итогу, а avif первым делом их подчистить пытается при сжатии, такая гипотеза.
Спрашивается зачем тебе тогда вообще чтото кодировать если ты просто источник копируешь
скачай avidemux там режет по ключевым кадрам, можно даже найти через прогу нужный тайминг и просто через ffmpeg прогнать его. Хуй знает в ffmpeg не хватает нормальной функции чтобы показал тебе все ключевые кадры видео.
Изначально вопрос стоял так:
>Как рендерить видео в Reaper без потери качества?
Reaper это программа для работы со звуком, ответ на вопрос - никак не рендерить, а просто скопировать если это возможно через какие-то опции в интерфейсе. Сам я с ней не работал поэтому примерно указал что искать.
> avidemux
Во, заработало! Вроде ровно и хорошо нарезало.
Чёт я раньше качал что-то резать и там что-то не срослось. А сейчас прям залетело заебись.
Провёл для себя небольшие сравнительные тесты, и выявил странности в функционировании пресетов. Суть:
Кодирую libx265 с заданным CRF 15, тестовое видео 4 минуты, blu-ray, даунскейл в 720р. Отличаются только пресеты.
Получаю:
1) medium, 7.5 минут, 171 МБ;
2) slow, 23 минуты, 186 МБ;
3) slower, 55 минут, 188 МБ;
4) veryslow, 90 минут, 187 МБ;
Мануал ffmpeg на тему x264/x265 говорит, что CRF задаёт качество, а пресет влияет на уровень сжатия и скорость кодирования. Соответственно, по логике, при одном и том же CRF я должен получать на выходе ~одинаковое качество, а размер файла (битрейт) должен уменьшаться от быстрых к медленным пресетам.
Результаты демонстрируют, что это совсем не так. На быстрых пресетах и размер меньше, и качество, очевидно, хуже. Т.е. всё-таки пресеты влияют на качество. При этом, совершенно не понятна взаимосвязь CRF vs preset. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
Хули за тебя должен читать первый же гайд по этой хуйне?
> Note that CRF values are different based on which preset you select, a "slower" preset generates more compression/bit, but may increase filesize.
> If you compare "ultrafast" with "veryslow" at the same CRF value, "veryslow" may generate a larger file, with overall better compression.
https://trac.ffmpeg.org/wiki/Encode/H.265
Там они сами себе противоречат.
>Choose a CRF. CRF affects the quality.
>Choose a preset. The default is medium. The preset determines compression options and efficiency and therefore affects encoding speed and size.
Вот приходит рандомный человек, читает азы. Вроде с ходу всё просто и понятно. Потом тут же пишут, что всё вообще не так, а хуй пойми как. Ебитесь сами, и понимайте как хотите.
>Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
Вопрос снят. Сам нагуглил. До сего дня даже не слышал ни про какие метрики. Делюсь результатами. Может, будет для кого-то полезно. Выводы делаю такие:
1) CRF ниже 15 не имеет смысла.
2) пресеты медленнее чем slow не нужны.
3) Оптимальный битрейт/качество за разумное время - crf около 20 + preset slow.
Вряд ли открыл что-то новое, кроме как для себя. Вроде как мои результаты в целом соответствуют бенчмаркам энтузиастов.
>>3693155
>>3693177
>При этом, совершенно не понятна взаимосвязь CRF vs preset. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Пресет отвечает за эффективность сжатия - соотношение качества полученного видео к битрейту. CRF по сути управляет выходным битрейтом.
Для одного и того же пресета: чем выше битрейт - тем выше качество.
Для одного и того же битрейта: чем медленнее пресет - тем выше качество.
>за разумное время
С учетом даунскейла до 720p - как-то медленно выходит, ты точно процессор полностью нагрузил? Алсо если нет каких-то аппаратных ограничений на воспроизведение - глянь в сторону AV1.
>С учетом даунскейла до 720p - как-то медленно выходит, ты точно процессор полностью нагрузил?
У меня комп 2014 года. Камень 4790K.
>если нет каких-то аппаратных ограничений на воспроизведение - глянь в сторону AV1.
Как-то пробовал из интереса, там скорость кодирования такая, что надо неделю ждать. Неюзабельно. Мне кажется, даже на современной пеке там не сильно веселее, если энкодер референсный программный, а не аппаратный.
Так-то мне для просмотра на старой ТВ-приставке, у которой максимум h264 и h265. Никаких AV1, VVC и т.п.
что на пикче? прога какая то или что?
> там скорость кодирования такая, что надо неделю ждать
ну на скорости 4 и 6 норм, почти как h264. хотя я тестил на коротких файлах - там разница минимальна по весу и качеству при одиноковом битрейте (потому что я всегда минимально достойно выглядящий низкий ставлю, это где то crf от 24 до 36) . выигрышь у av1 идёт на больших файлах. а если надо сжать короткий ролик быстро - старичок avc.
хотя я юзал av1 svt. libaom получше сжимает особенно на низких скоростях. но и это дольше конечно. я пока с пресетами игрался у меня всё термопаста засохла на проце а я недавно менял.
Ванильный svt? Форки не пробовал?
https://github.com/Uranite/svt-av1-tritium
https://github.com/juliobbv-p/svt-av1-hdr
>что надо неделю ждать
Нет такого давно. Разве что ты нулевой пресет выставил.
>>3693205
FFMetrics
>>3693207
Да, я скорее всего libaom пробовал. Но мне в целом AV1 не интересен, т.к. всё-равно негде его воспроизводить.
>негде
potplayer, mpc
Если аппаратно не воспроизводится, то нахуй ненужен. Это как анимешный х264 10бит.
мимо
Жопочтец? Речь не про комп.
21.11.2025 11:12 (MSK)
Компании HP и Dell в ряде современных ноутбуков намеренно отключили аппаратное декодирование видео с использованием видеокодека HEVC (H.265), хотя используемые процессоры AMD и Intel технически поддерживают эту возможность. HP упоминает об отключении аппаратного ускорения HEVC в спецификациях некоторых моделей ProBook и EliteBook. У Dell ситуация менее прозрачная - официальные спецификации не содержат предупреждений, однако служба поддержки компании подтверждает, что HEVC недоступен на базовых конфигурациях без дискретной графики, 4K-экрана или пакета мультимедийных лицензий.
Обе компании отказались объяснять причины такого решения. Предполагается, что отключение вызвано стремлением сократить лицензионные расходы: с января увеличиваются лицензионные отчисления за каждое устройство с поддержкой HEVC, и отключение функции позволяет производителям формально избежать дополнительных платежей.
>200-300 только
Это значит что за сутки ты почти год своего аниме перемолотишь.
Нахуй тебе быстрее?
Пока видеокарту тебе доставлять будут ты натранскодишь больше времени контента чем тебе жить останется.
Не зря почитал тредю, удобная программа, как раз искал способ конвертировать много файлов за раз
И чот бегло поглядел по пресетам видео, не увидел в списке ваш новомодный AV1, такой же непонятный и неуловимый как для аудио DSD вроде бы, со странной частотой дискретизации в 1.5 МГц
Ой чот мне не нравится, что на выходе 900 МБ вместо приятных 200МБ, ой фу ваш ffmpeg
>crf=28 vs crf 23
>а чего сжимает сильнее
Это сраказм?
Нет, я настроек не знаю и потому приходится просто экспериментировать чтобы и качество не всратое и вес небольшой, в ShotCut настроек по умолчанию за глаза, но я не нашёл как сразу несколько файлов пережать
ффмпег всё умеет.
Умеет, но если у тебя остаётся всего одна дорожка, то как-то так:
ffmpeg -hide_banner -i video.mp4 -i audio1.opus -i audio2.opus \
-map 0:v -map 1:a -map 2:a \
-metadata:s:a:0 language="ru" -metadata:s:a:0 title="Первая дорожка" \
-metadata:s:a:1 language="ru" -metadata:s:a:1 title="Вторая дорожка" \
-c copy -y video_out.mkv
Благодарю, попробую
И ещё вопрос. Результат сжатия видеокартой, конкретно серии 6000, может отличаться, от результата процессором при одинаковых настройках?
>Результат сжатия видеокартой, конкретно серии 6000, может отличаться, от результата процессором при одинаковых настройках
Разные библиотеки используется, значит будет отличаться. Причём сильно, на GPU качество всегда заметно хуже при одинаковом размере файла.
Там не библиотеки, там готовый независимый модуль кодировщика куплен и вставлен в схему чипа на этапе производства. Он аппаратно реализует все нужные части алгоритма, на входе получает буфер в памяти с кадрами, на выходе выдаёт готовый сжатый поток видео в другой буфер.
Бытовые кодировщики (в компьютерах, смартфонах, приставках и прочем) в первую очередь нацелены на работу в реальном времени (с маленькой задержкой). Как они используются? Видосик снимают смартфоном, он сразу кодируется и сохраняется. По видеосвязи общаются, видео с камеры кодируется и сразу улетает. Игру или фильм передают на другое устройство в нужном формате (или на сервис вещания в интернете), всё то же самое. Их задача выдавать достаточное для типичных условий просмотра качество и при этом не быть слишком сложными/дорогими в производстве. Профили сжатия для того и стандартизированы заранее, чтобы сложные в реализации части на каких-то устройствах можно было без вреда опустить. Подразумевается, что если кому-то и нужно качество повыше, то почти всегда можно достичь этого, задрав аппаратному кодировщику битрейт. Для вылизывания параметров сжатия они не предназначены, поскольку многие детали там просто фиксированы.
А если надо и быстро, и максимально качественно, и чтобы работало 24 часа в сутки, то есть студийная техника, которая стоит как автомобиль.
Я flac, если он есть, на диски пишу, даже 700 1000 бит рейт за глаза
Есть и старые диски с качеством как на картинке, конечно звучит отлично, но место не резиновое
Значит мне не показалось, получается ситуация как с рендерингом на видео и процессором в каком нибудь vray
Буду экспериментировать дальше, видяха конечно быстрее, даже процессора 3950
Ну шутка-то в том, что даже 128 кб/с, который пафосно называли неотличимым от оригинала, на самом деле не годился, а тут WMA в 64 кб/с, который булькал и дзынькал ничуть не меньше, чем MP3 первых лет на таком же битрейте. Только LAME потом годами оптимизировали, чтобы артефакты как можно лучше скрывать на типичных звуках, а WMA вскоре стал не слишком нужным. Нахальство Microsoft, которая тогда пыталась подмять под себя весь мир и все индустрии сразу, не знало границ.
В интерфейсе Windows Media Player для сохранения музыки с дисков уже скромнее были и рекомендовали 128 килобит.
>FFmpeg Batch AV Converter
Надо попробовать. Есть ещё Shutter Encoder, тоже надстройка над ffmpeg
>>3693816
>Какая самая лешевая видеокарта для апаратного кодирования AV1, мне нужно, аниме, фильмы, сериалы перегнать в него для жкономии места.
Думаешь видеокарта будет дешевле ещё одного жёсткого диска?
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
>что ты хочешь получить, то просто зря потратишь время и электричество.
Классика жанра же!
> Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Если человек знал что хотел, то результат своим требованиям в тот момент полностью соответствовал. А современные мониторы и объёмы хранилищ просто в них не входили.
Ну так HEVC - лицензируемая параша, и с каждого устройства с его аппаратной поддержкой надо уплатить НОЛОГ за воздух, иначе суды, штрафы, санкции, гроб, кладбище. Поэтому у VVC-параши нет будущего, везде будет AV-1 (и H264).
Ну и чо теперь делать? У меня карта может только 265 кодировать, а ваш ав нет, ещё и проигрывателю плугин нужен
Ну его нахуй
Если тебе в 1-ю очередь важно качество, то любые аппаратные кодеры - это кал, т.к. производят немало артефактов.
Чего я ожидаю: я указываю ему начальное и конечное время из некого видео и затем при запуске сжатия он заодно его и порежет
Чего получается на выходе: жмёт и обрезает
На кнопку нажимал, он ошибку выдаёт
Разобрался проблема была в том, что он не может или не хочет перезаписывать файл, так как я сохранял туда же и с тем же именем уже обрезанный файл есть в этом смысл, так как он сначала делает пустышку-заготовку с именем, а в процессе туда инфу заливает
>ой фу ваш ffmpeg
Ты в курсе, что в твоем шорткат тоже ffmpeg?
Да, в нём настройки по умолчанию дают результат, который меня устраивает, на данный момент я уже подобрал параметры, так что проблем нету
так обычно и происходит это не способ плохой это просто ты не разобрался. (личное моё наблюдение) все способы которые обещают быстрый однокнопочный результат - компромиссные и уступают по качеству. а если хочешь лучше - надо разбираться. но в ffmpeg хорошо то что он универсален, один раз надо только разобраться и потом всю жизнь можно пользоваться в отличии от того чтобы прыгать от проге к проге и каждый раз заново учится с ней работать
Добавь -y в команду, тогда будет перезаписывать файл.
При старте обучения всегда идёт копирование рабочего примера, ещё лучше, если есть пример под конкретную задачу, а потом уже идёт рост вширь с изучением тонкостей
Я даже теорию придумал, два типа обучения
Обучение копированием - быстро, но нет гарантии запоминания
Обучение через открытие - некое самостоятельное исследование с набором небольших знаний, изучение всяких источников и потом на основе этого само открытие - долгий, неопределённый по затратам времени процесс, но результат запоминается навсегда
>>3695181
Попробую
охуительное открытие, зайди в патентное
хорошо так и оставлю 1.2 гб за 6 минутную серию аниме в 1080п, не ну что зачем мне экономить место и возиться с этиси кодеками и настройка, просто увеличу место, у меня же корпус бесконечный и три блока питания в каждом по 20 сата портов.
Есть видеодорожка анимации с ютуба, хочу ровно по кадрам вырезать одну её часть. В картинки извлечь получилось, нужный диапазон кадров знаю. Хочу сделать это без перекодирования — MP4 (libdav1d) —> AVIF (libdav1d). Это реально?
MP4 это видеоконтейнер, AVIF это формат хранения изображений. Очевидно нет, нельзя.
>>3696460
что думаешь не стоит?
там еще ютуба есть, но там поменьше около ста гигов, и половина скачана как раз в ав1 так как вес меньше на треть, а то и половину, что позволяет скачать в большем разрешении
Да, это реально. Поскольку и ваш исходный MP4 (AV1), и целевой AVIF используют один и тот же стандарт сжатия (AV1), вы можете просто перенести видеопоток в новый контейнер без перекодировки (remuxing).
Однако при работе «по кадрам» без перекодировки есть нюанс: обрезка возможна только по ключевым кадрам (I-frames).
Как это сделать:
Если нужно вырезать один кадр (статичный AVIF):
Убедитесь, что выбранный кадр является ключевым. Если это так, используйте команду:
ffmpeg -ss [время_или_номер] -i input.mp4 -frames:v 1 -c:v copy output.avif.
Если нужно вырезать диапазон (анимированный AVIF):
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output.avif.
Важно: Если вы начнете резку не с ключевого кадра, плееры могут отображать черный экран или артефакты до первого встреченного ключевого кадра.
Если нужно чтобы каждый кадр был отдельным изображением:
ffmpeg -ss [старт] -to [конец] -i input.mp4 -c:v copy output-%04d.avif
Именно, знать что-то не равно понимать и применять на практике.
> разные файлы
> сжимаются по разному
Хуй знает о чём ты говоришь. Спрашивай нейросетку такие тупые вопросы.
Слишком много лишней информации на скриншотах и в тексте твоего поста, обрежь ещё сильнее картинки, а текст сократи до одного предложения в 30 символов. Чтобы уж точно было интересно разгадывать загадку-шизофазию, экструдированную из твоего пропитого стекломоем рта.
>>3696936
Эх, а я надеялся, что мне ответят умные люди, которые разбираются в тонкостях сжатия 265. Промолчали бы что ли, тут вроде бы не ваш личный бложик, где вы ЧСВ тешите
Либо ты даёшь нормальные вводные, с хотя бы двумя этими разными файлами, либо идёшь нахуй как жирное дерьмо
ты вопрос сначала нормально задай, а потом обижайся
мы откуда знаем, че ты там сжимаешь
>разные файлы
>количестве кадров
такой ответ устроит? или ты не можкшь связать две взаимосвязанные вещи?
Альянс AOMedia начал разработку нового звукового кодека OAC на базе Opus
Аноним (Microsoft Windows 10: Firefox based)
23/02/26 Пнд 03:23:50
№
367
Главная цель OAC заключается в качественной передаче звука и речи через интернет. Кодек отлично подходит для интерактивных задач, включая голосовую связь, видеоконференции, игровые чаты и удаленные музыкальные трансляции. Формат легко масштабируется, позволяя сжимать как высококачественную стереомузыку с высоким битрейтом, так и обычный голос в условиях ограниченной пропускной способности сети.
На данный момент проект находится на ранней стадии разработки. Создаваемый библиотекой битовый поток пока не рекомендуется использовать для распространения файлов, поскольку он содержит отладочную информацию и временно не поддерживает перемотку. Технические характеристики OAC во многом наследуют базовые возможности Opus версии 1.5. Новый кодек поддерживает битрейт от 6 до 510 килобит в секунду, частоту дискретизации от 8 до 48 килогерц и продолжительность кадров от 2.5 до 60 миллисекунд. Кроме того, реализована поддержка постоянного и переменного битрейта, работа с количеством каналов вплоть до 255, а также возможность кодирования как узкополосного, так и широкополосного звука. Разработчики предусмотрели алгоритмы восстановления звукового потока при потере пакетов данных и поддержку вычислений с плавающей и фиксированной запятой.
https://www.opennet.ru/opennews/art.shtml?num=64852
> прямое развитие популярного формата Opus
Тоесть 44100 опять не будет? Ясно понятно.
Хз. Там же не написано.
Частота дискретизации от 8 до 48KHz;
Просто вот эти диапазоны
> битрейт от 6 до 510 килобит в секунду
> частоту дискретизации от 8 до 48 килогерц
точь-в-точь как у опуса, в сочетании с
> как прямое развитие популярного формата Opus
> во многом наследуют базовые возможности Opus версии 1.5.
наводит на подозрение что поелозят напильником, подвигают ползунки и назначат готовым без каких-либо фундаментальных изменений. А в опусе 44100, 22050, 11025 - нет, и это по словам разработчиков by design, мол мы супер-дупер разоптимизировали под 48000, остальное ненужно, ебитесь как хотите.
А тебе 44 критично что ли? Щас все цапы на 48к работают один хрен.
Для меня - да. Вопрос был - жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что музяка выходила сто лет в 44100, да сейчас значимая часть выходит, а задирать битрейт чтобы скомпенсировать потери на ресэмпле - не шибко много наэкономишь. Когда я это решал еще и поддержка опуса была далеко не везде.
>задирать битрейт чтобы скомпенсировать потери на ресэмпле
Шо за хуйню я читаю. Во-первых, битрейт ортогонален сэмплрейту, потому что кодек всё делает в спектральной области. Если он, условно, видит две синусоиды, он их кодирует как две синусоиды независимо от того, в каком они сэмплрейте. Сэмплрейт в спектральной области это лишь масштабирующий коэффициент на шкале частот. Во-вторых, ресэмпл ты один хуй делаешь, но только если ты делаешь его при кодировании, то ты делаешь его один раз и без спешки, а если ты делаешь его при прослушивании, то ты его делаешь при каждом прослушивании и в риал тайме, т.е. более быстрыми = более грубыми алгоримами.
Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями. Невыжно как он ее воспринимает теперь - она уже искажена.
> ресэмпл ты один хуй делаешь
Схуя ли?
Значение имеет не эта менюшка, а какой кварц к ЦАПу припаян. ЦАПы под капотом тоже умеют делать ресэмплинг.
>Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями.
Ресэмплинг в теории можно сделать сколь угодно близким к идеалу. А на практике — настолько близким, чтобы выход алгоритма кодирования совпадал для обоих вариантов бит в бит. И ровно для этого и имеет смысл делать ресэмплинг не на лету, а заранее.
а при глухих тестах?
Вот на ютубе есть функция ускорения видео. При этом, звук не становится хай-питч, как при ускорении в обычном плеере. Собственно, а можно ли в MPC или ином видеоплеере добавить такую же функцию? По какому принципу это вообще реализовано?
View - Options - Audio - Audio renderer - MPC Audio Renderer
>По какому принципу это вообще реализовано?
Оконное преобразование Фурье. Сначала прямое, потом делают окна шире/реже или чаще/уже, и обратное.
Хм, спасибо! Оказалось, у меня была настолько древняя версия MPC, что там такого ещё не было. Накатил свежий кодек-пак с MPC, теперь заебца.
>>3697675
Понятно. Не для моих жидких мозгов.
Да ничё сложного, спектрограммы видел когда-нибудь? Вот делают сначала из аудиодорожки спектрограмму, потом сжимают её во времени или растягивают, чтобы частоты при этом никуда не съезжали, потом обратно превращают в звук.
>жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что
Потому что опус не для этого, дегенерат.
Он именно для речи и для передачи по сети задуман и заточен, поэтому там никаким тюнингом ни под хранение, ни под музыкальную индустрию и не пахнет. Зато почти реалтайм – а тебе это на кой чёрт?
Ну и этот новый опус ровно туда же двигается.
А что по твоему лучше подходит для музыки? aac? если конечно не flac
Живые музыканты с настоящими инструментами, только так и никак иначе.
Для хранения – вообще что хочешь.
Любая эзотерическая хуйня, тебе же не надо чтобы кто-то кроме тебя это умел воспроизводить.
Vorbis наверное, но хуй знает точно. Я бы ёбнул пару треков конкретно твоих хотя бы в Vorbis, AAC, AC3, AVS2 и посмотрел.
Помимо AAC у MPEG ещё дохуя разных кодеков ебал в рот их номенклатуру да и у самого AAC уровней тоже хватает.
А если электронная музыка?
> Потому что опус не для этого, дегенерат.
Ты бы не охладил траханье, углепластик?
На их собственном оффсайте
> It can scale from low bitrate narrowband speech to very high quality stereo music.
Так что не пизди тут.
Целиком этот абзац хотя бы приведёшь?
>Opus Interactive Audio Codec
>Overview
>
>Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications. It is standardized by the Internet Engineering Task Force (IETF) as RFC 6716 which incorporated technology from Skype’s SILK codec and Xiph.Org’s CELT codec.
>Technology
>
>Opus can handle a wide range of audio applications, including Voice over IP, videoconferencing, in-game chat, and even remote live music performances. It can scale from low bitrate narrowband speech to very high quality stereo music. Supported features are:
>
> Bitrates from 6 kb/s to 510 kb/s
> Sampling rates from 8 kHz (narrowband) to 48 kHz (fullband)
> Frame sizes from 2.5 ms to 60 ms
> Support for both constant bitrate (CBR) and variable bitrate (VBR)
> Audio bandwidth from narrowband to fullband
> Support for speech and music
> Support for mono and stereo
> Support for up to 255 channels (multistream frames)
> Dynamically adjustable bitrate, audio bandwidth, and frame size
> Good loss robustness and packet loss concealment (PLC)
> Floating point and fixed-point implementation
>
>You can read the full specification, including the reference implementation, in RFC 6716. An up-to-date implementation of the Opus standard is also available from the downloads page.
Дальше что?
История:
Разработан в 2012 году организацией IETF (Инженерный совет интернета) в результате слияния двух кодеков: SILK (от Skype) для речи и CELT (от Xiph.Org) для музыки. Это объединение позволило ему одинаково хорошо работать с любым типом звука. В 2017 году он стал обязательным стандартом для браузеров и WebRTC (технологии потоковой передачи).
Предназначение (ключевые особенности):
1. Универсальность: Заменяет сразу несколько кодеков (MP3, AAC, Speex). Одинаково эффективно сжимает как человеческий голос (от 6 кбит/с), так и сложную музыку (до 510 кбит/с).
2. Низкая задержка: Идеален для стриминга, видеозвонков и онлайн-игр, так как имеет минимальную задержку при кодировании.
3. Открытость и бесплатность: В отличие от MP3 или AAC, за его использование не нужно платить лицензионные отчисления (патенты), поэтому он широко поддерживается всеми браузерами и приложениями (Discord, Spotify, YouTube).
>Ты бы не охладил траханье, углепластик?
Какой слог!
>>3697795
>>3697800
>>3697796
>>3697795
>>3697704
>>3697593
>>3697545
Дауны, о чём вы спорите?
По аудио форматам всё давно разжёвано:
https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
Для музыки 320-500 кбит/с - лучше всего ogg (libvorbis).
Для всего остального - opus. Его единственный реальный недостаток - срез на 20 кГц, даже на высоких битрейтах.
По своему опыту - я за огг, потому что он древний, как говно мамонта, и поддерживается многими аппаратными плеерами, тв-приставками и т.п. (даже с битрейтом 500 кбит/с), в отличие от опуса, поддержка которого распространёна лишь на компах и смартфонах.
Мне кажется, если у него анимцо и задача в 3-5 раз ужать, то hevc (libx265) -preset medium -tune animation -crf по вкусу - норм решение.
>срез на 20 кГц
Так частоты выше 20 кГц не воспринимаются человеком же. Зачем они тебе? Или это какая то аудиофильская приколюха типо даже если частоты не слышишь они всё равно могут как то влиять на прослушивание?
Так и разницу между 128 и 320+ кбит/с не слышно. Зачем тебе такой высокий битрейт?
На opus? мне слышно, у меня хороший слух и наушники, хотя конечно не супер студийное оборудование ценой в квартиру. лично я храню в opus 256vbr, конвертируя flac в opus в foobar2000 через актуальную версию opus энкодера, с настройками --vbr --bitrate 256 --comp 10 --expect-loss 0 --ignorelength - %d. lossy и 32-bit float. ещё на всякий advanced limiter и resampler (dbpoweramp/ssrc) на 48к hz
>Его единственный реальный недостаток - срез на 20 кГц
Это достоинство. Это означает, что психоакустическая модель опуса сделана по науке, а не по чьей-то магической шизе.
ffmpeg -f lavfi -i smptebars=s=1920x1080 -c:v libx265 -pix_fmt yuv420p10le -x265-params "hdr10=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):max-cll=1000,400:atc=16" -to 5 -y output_1000nits_smptebars.mkv
>>3697924
Если говорить про битрейты 320+, то они и так дают чрезмерное качество, не отличимое от 192-256. Когда на 500 кбит/с срезаются 20 кГц - это и есть шиза. На таком битрейте нет проблемы сохранить 20-22 кГц. Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
>https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
чёт не открывается, пикрил выводит а потом "страница недоступна"
http://web.archive.org/web/20260110213002/https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
Наркоман.
ffplay -f lavfi -i "smptebars"
>Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
Какой впечатляющий поток отборной шизы.
"libopus"- Usable range ≥ 32 Kbps. Recommended range ≥ 64 Kbps.
Transparency (music): Very close at default (96 Kbps), but takes more (160+) to be real transparent.
Transparency (speech): ~ 32 Kbps.
Опус намного лучше.
Я в слепом тесте разницы не услышал в мп3 между 320 и 192 на сложном треке с кучей высоких частот. Тесты были на e-mu 0204 и сенхах 598. Че уж говорить про более лучшие форматы как аас и опус.
Задача кодека жать аудио в соответствии с психоакустической моделью, а не удовлетворять твои представления о прекрасном. Это помимо прочего ещё и бессмысленно, сегодня тебе надо чтобы на выходе кодека были частоты >20кГц, а завтра чтобы на спектрограмме рисовались хуи.
Размер на диске 8 и 9 мб
Они же во FLAC занимают 21 и 25 мб.
>>3698017
>>3698061
Да вы тут все шизики. Лично я про форматы с потерями забыл ещё в 2010 году, когда со стипендии купил себе винт аж на 1 ТБ. Тогда же перестал записывать на двд и сд. С тех пор вся музыка во флаке, теперь даже на смартфоне (256 ГБ + 1 ТБ сд карта). Сейчас у меня вся фонотека (80+% которой я практически не слушаю) - жалкие 1.8 ТБ, при доступных 14 ТБ. В подтверждение того, что я давно практикующий меломан, прилагаю счётчик фубара за последние ~15 лет.
В общем, в 2026 году не вижу ни малейшего смысла хранить музыку в лосси форматах. Разве что вы совсем уж отмороженные шизики-архиваторы, которым надо скачать и хранить ВСЮ музыку, 99+% которой вы ни разу не прослушаете.
Кстати, фильмы и сериалы на компе давно не храню, потому что за годы осознал, что повторно ничего не пересматриваю. Посему - скачал-посмотрел-удалил. Храню только музыку (концертники), но объём тоже смешной, ~800 ГБ.
Двачаю, вон на двух файлах выше - так везде, разница ну в три раза. Размер станет заметен, если пытаешься сохранить всю музыку мира.
> практикующий меломан
> меньше часа в сутки
А бэкап? Когда он у тебя сдохнет - локти будешь кусать. У меня коллекция в 2х бэкапах.
У меня во флак только своя музыка, которую я написал, остальное - мп3, аас, огг и т.д.
>>3698078
Audio: Opus 48000Hz stereo 3072kbps
Ты че дурак? Ужми в 96 кб (уже прозрачное качество), и там не в 3 будет а в сто.
А, не, 332 kb/s. Чет плеер гонит мой. Но все равно 96 кб\с уже в 3 раза меньше, чем 320. Итого выйдет раз в 10 сохранение размера с таким же качеством.
Тебе сколько лет, мальчик? С годами всякое дерьмо начинается (работа, семья). Последние 8-10 лет если удаётся вечерком хоть час послушать музыку дома, сидя перед компом - это прям в диковинку. А так - смартфон+автомобиль.
>>3698082
Нашёл кому рассказывать. В шкафу винтов на ~20 ТБ, не считая всякий антиквариат.
>В шкафу винтов на ~20 ТБ,
А у меня ток 3.5 где-то. И большая часть забита проном. Не могу себе позволить так раскидываться местом.
Это остатки роскоши со старой РАБоты. Из списанных компов надёргал больше 100 кг железа, в т.ч. винтов.
>сегодня тебе надо чтобы на выходе кодека были частоты >20кГц
Что не так с частотой >20кГц?
Допустим формат у тебя по факту имеет 22050 Гц, то есть семплы выплевываются с частотой 44100 Гц.
Допустим, в оригинале был простой сигнал в 16 бит, сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли. То есть фронт прямой и резкий.
Теперь ты берешь и фильтруешь, отсекаешь все что выше 20кГц нахер. Что получается на выходе? Получается фронт не резкий, а размазанный. На семплах будет гребенка возле фронта.
>Или это какая то аудиофильская приколюха типо даже если частоты не слышишь они всё равно могут как то влиять на прослушивание?
Да. Ты их сами частоты не слышишь. Но они влияют на слышимые частоты. Вдобавок, косвенно они ощутимы и придают звуку настоящети.
> сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли
У тебя динамик не идеальный. Такой резкий щелчок породит на нём точно такой же переходный процесс (и ты его точно так же не услышишь).
И чтобы закодировать эту гребенку нужно место, которое берется из битрейта.
>Допустим, в оригинале был простой сигнал в 16 бит, сначала шли все нулевые семплы, потом с какого-то момента все 30000 пошли. То есть фронт прямой и резкий. Теперь ты берешь и фильтруешь, отсекаешь все что выше 20кГц нахер. Что получается на выходе? Получается фронт не резкий, а размазанный. На семплах будет гребенка возле фронта.
Ты просто недоучка, который думает, что цифровой звук восстанавливается ступеньками. У нормальных пацанов цифровой сигнал типа "0, 0, 0, 0, 30000, 30000, 30000, ..." будет точно так же восстановлен с гребёнками и заваленным фронтом, потому что матан предписывает так его восстанавливать. У тебя будет на 0.01% более частая гребёнка и на 0.01% менее заваленный фронт, так это и работает.
Но ты эти 0.01% не услышишь, потому что мочёные не зря определили 20кГц как физиологический потолок слуха.
>>3698174
По сути верно, но с уточнением, что этот переходный процесс возникнет даже до динамика, ещё на выходе ЦАПа.
>>3698175
Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
Странно, а научные исследования, физика и тесты говорят об обратном.
Да даже на мелких, но хороших, динамиках слышу что FLAC более трескучий чем MP3.
Не, такое возможно, если в системе существует нелинейность. Но это лишь означает, что надо не больше частот покупать, а больше линейности.
Ты не то сравниваешь. Сравнивай flac 44100 c фильтром 20кГц и без фильтра. Тогда это будет иметь отношение к разговору о слышимой полосе частот.
>Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
Если у тебя формат внутри своего устройства ограничен верхней планкой 20k то не нужно, а если 22050 или больше, то нужно.
>У нормальных пацанов цифровой сигнал типа "0, 0, 0, 0, 30000, 30000, 30000, ..." будет точно так же восстановлен с гребёнками и заваленным фронтом, потому что матан предписывает так его восстанавливать.
Если восстанавливать в повышенную частоту дискретизации, то нужны гребенки. Если если в аудиосистеме такая же частота, что и в формате, то нелинейные искажения только в аналоге будут от переходных процессов, а в цифре такой же сигнал.
Точно, надо попробовать. Вдруг это FLAC раскодируется с ошибками (без среза частот >20k хех мда).
Хоть он и шиз, но и ты тоже пишешь хуйню.
На выходе любого ЦАПа стоит активный фильтр на ОУ, который подавляет всё что выше 20 кГц. Да, даже если ты пытаешься воспроизвести 96/192 кГц на канал. Обычно частота среза ~50 кГц, при этом в районе 20 кГц начинается спад в пределах -0.1 дб. Большинство производителей ЦАПов приводят рекомендуемый дизайн фильтра в даташитах, либо аппнотах. Пикрилейтед - из даташита CS4398. Кроме того, реальная конечная нагрузка (динамик/капсюль) обладает большим реактансом, и чистый меандр ты ну никак не получишь. Конечно, можно согласовать выходное сопротивление, но только для конкретной частоты.
>Если у тебя формат внутри своего устройства ограничен верхней планкой 20k то не нужно, а если 22050 или больше, то нужно.
Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
>Если восстанавливать в повышенную частоту дискретизации, то нужны гребенки.
Если восстанавливать идеально или хотя бы качественно, то нужны гребёнки. Чем дальше ты от гребёнок — тем дальше ты от корретно восстановленного аналогового сигнала.
Ещё раз, это матан так работает. По теореме отсчётов, существует только один способ восстановить сигнал из отсчётов, если он соответствует критерию Найквиста. Если ты от этого однозначного восстановлия отходишь — ты вносишь искажения в то, что содержится в цифровом представлении. И даже если тебе это кажется более "правильно", типа ступеньки более резкие — это только следствие твоего невежества, и никто с минимальными знаниями по теме в реальности так не делает.
Нахрена такую подставу делать? Какой смысл?
>Нахрена такую подставу делать? Какой смысл?
Подключи прямо на выход ЦАПа спектроанализатор с полосой 1-10 МГц и попробуй сам догадаться.
256кб/c vbr это слышимый предел для опуса даже если у тебя золотые уши. я тестил много и не заметил разнину с флаком. да я даже с 192кб vbr разницу только в 2 из 10 раз видел
Только собственные личные ансамбли, оркестры и композиторы играющие оригинальную музыку и любые высококлассные каверы в любом стиле по твоей просьбе, только хардкор.
Ну и тёплый, ламповый винил.
Потому что носятся со своей психоакустикой, как дурни.
ну если лично я разницы не слышу, то стоит ли трястись? 256vbr опус мне за глаза. сколько пытался услышать разницу с флаком - не услышал. а вы сами решайте. musepack, vorbis, mp3 = устарели, форматы зомби. сейчас актуальны и обновляются только aac и opus, всё остальное lossless (а там только flac, ну и разве что WavPack и Monkey's но нахуя)
Ну тупые, не то что некомпетентное диванное шизло с магическим мышлением вроде тебя.
> Только собственные личные ансамбли, оркестры
Заодно можно почувствовать себя худруком
Сравнил. Разницы практически не слышу. Но как будто она есть. Видимо нужна топ аппаратура, чтобы понять.
>>3698197
>Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
Ну вот я сжал во флак, оригинал и фильтровку. Фильтровка ужалась чуть хуже.
test это сгенерированные одиночные семплы 32767 через каждые четверть секунды
Вижу высокие частоты. Это для того чтобы плебеи их не слышали или для того что раз аппаратура говно, то нечаго наворачивать частот?
>Ну вот я сжал во флак
Я про lossy-кодеки говорил. Надо было это уточнить, да. FLAC не использует психоакустическую модель и не раскладывает звук на частоты.
Вывод такой. Что может что нибудь особенное будет ощущаться на >20кГц, но не на моей аппаратуре, точно.
Если у тебя есть телефон, поставь на него Spectroid и посмотри спектр с микрофона, играя на колонки 21кГц (сэмплрейт поставь >48кГц, естественно). Увидишь, что твой динамик-пищалка эту частоту прекрасно играет, телефон её прекрасно слышит, а ты её не слышишь просто.
>>48кГц
в смысле, >=48кГц, больше или равно
А если лобные доли сформировались, то выше 16КГЦ
ВРЁТИИ, Я ТАК ПРИМЕРНО ПРОЧУВСТВОВАЛ
мимо диванное шизло с магическим мышлением
Вообще, то что осознанно не слышишь те частоты не значит что не воспринимаешь их совсем.
Попробуй вместо синусоиды музыку послушать в полном спектре и в обрезанном, скорее всего вслепую спокойно отличишь.
То же самое со светом, например. Близкие к видимому спектру ультрафиолет и инфракрасный ты не видишь, но от первого быстро глаза начинают болеть, а второй воспринимается как температура. Т.е. цвета ты не отличаешь, но организм на них реагирует.
Я в этих вопросах нуб, выручай анон. и что опять с капчей из под куклы не грузится
Ты б хотя бы mediainfo своей перекодировки в другой формат полностью приложил.
For all practical purposes in music listening, a 20 kHz low-pass filter is inaudible. The "cutoff" of, for example, 44.1 kHz digital audio (which cuts off at 22.05 kHz) is rarely noticed, and 20 kHz is often the standard, safe limit for mastering.
People generally start noticing a low-pass filter (LPF) cutoff in audio when it is set below
10–13 kHz for high-fidelity music, as this removes "air" and brilliance. For voice, audible degradation often begins around 5–7 kHz, while filters below 2–5 kHz make audio sound muffled or telephonic.
< 15 kHz (Subtle): Loss of "air," "sheen," or high-frequency brilliance.
10 kHz–12 kHz (Moderate): Loss of crispness and definition in percussion and vocals.
5 kHz–7 kHz (Noticeable): Audible dulling of voice, loss of articulation.
< 3 kHz (Severe): "Telephone" or "radio" effect, making sound muffled.