Ждём AV2...
> Кодек AV2 продемонстрировал снижение битрейта на 30% при уровне качества AV1
https://www.opennet.ru/opennews/art.shtml?num=64033
https://www.opennet.ru/opennews/art.shtml?num=64033
Что ты с ним будешь делать?
Значит ли это, что битрейт надо поднимать до 30%, чтобы избежать "качества" AV1?
Вряд ли, ав1 ни на одном битрейте мыльной парашей не перестаёт быть, значит и саксесор должен эту же философию перенять.
> саксесор
Навуходоносор. Блядь. Зумереще ебаное.
(Не знаю, где спросить, тут или в /pr. Сразу скажу, что регистраций во всяких нейрочатах нет, там спросить не могу, так что спрошу тут)
Есть дохуя пикч весом от 3 до 6 мб (почти 1 тб в общем весе). Нужно осовбодить место. Нужно разом все пикчи сжать до минимального "читабельного" разрешения, т.е. чтобы весило до 1 мб, но при этом не шакальные пиксели были. И главное чтобы оригинал пикчи сразу удалялся и оставалась сжатая копия. Как сделать? Удалять не вариант. По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней. Помогите пожалуйста шарящие.
Есть дохуя пикч весом от 3 до 6 мб (почти 1 тб в общем весе). Нужно осовбодить место. Нужно разом все пикчи сжать до минимального "читабельного" разрешения, т.е. чтобы весило до 1 мб, но при этом не шакальные пиксели были. И главное чтобы оригинал пикчи сразу удалялся и оставалась сжатая копия. Как сделать? Удалять не вариант. По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +100500 часов, а то и дней. Помогите пожалуйста шарящие.
JEPG XS вроде может. JPEG XL в точный вес не может. BASH скрипт пиши.
>JEPG XS
Фикс, "JPEG XS".
>Сразу скажу, что регистраций во всяких нейрочатах нет, там спросить не могу
Попробуй duck.ai
>Как сделать?
Скриптами, но у тебя довольно много неизвестных ("читабельное разрешение", "не шакальные пиксели", формат пикч, ОС...), представление о которых есть только у тебя.
Там ограничения какие-то есть на кол-во запросов/время/длину беседы и т.п.?
jpegli от гугла почти как jpegxl, но в нормальном и поддерживаемым расширением везде. А не говно в .jxl
https://github.com/google/jpegli
> По отдельности каждый файл вручную сжимать и удалять ориг, оставляя копию не вариант, это займет +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 пресете.
> ЖпегХЛ умер
Он умер только в хроме. Софт его поддерживает, даже адобе. Еще недавно японцы запилили аппаратный кодировщик.
> хэйк остаётся норм вариант
Серьезно? Только яблоко его продвигает (продвигало?), и они теперь "мертвый" жрегхл поддерживают из коробки на своих устройствах.
> Он умер только в хроме
Т.е. буквально в большей части интернета
Чел приводит в пример хеик как норм вариант, хром его тоже не поддерживает.
Я вангую, что у хейка будет поддержка везде — на базе того что ведро с айосью его поддерживают — а с жпегXL пока влажненько выглядит, что в долгой перспективе он выживет. С хейком всё просто и понятно, тогда как XL привязан к обязательному колорменеджменту со своими наркоманскими профилями цветовых пространств. Но это гадание на кофейной гуще, конечно.
Сажа прилипла.
Да хуй знает, он же реально странно выглядит со своим сжиранием шумов и текстур, сколько сравнивал, всё не могу понять куда его ставить по качеству сжатия — на парашу хуже жпега или в недосягаемый остальными форматами топ. Склоняюсь к первому.
Одна строчка в каком нибудь nconvert.
nconvert -recurse -D -out webp -ratio -rflag decr -resize fill 1920 1080 *
Вот, например, рекурсивно пройдет по каталогам, все картинки конвертнет в webp, и до кучи все крупные картинки впишет в фулл ашди, оригиналы удалит.
Есть кто шарит и тестил, насколько svt av1 3.1.2 лучше чем старый 2.3.0? Расскажите все плюсы, минусы, что по качеству и есть ли смысл обновляться.
Мне сложно сказать насколько, но обновиться определенно стоит. Плюсы - оптимизация, новые настройки и улучшения с экспериментальной версии, фиксы каких-то багов. Минусов никаких.
Увожаемые анончики, подскажите пожалуйста команду которой можно к видео картинку превью добавить или может как-то можно указать кадр который будет использоваться для превью.
В гугле забанили? И в яндексе тоже?
Насколько я знаю превьюха выбирается случайным образом из начала видео и задать ее нельзя.
Гугл направил меня в этот тред, сказал что он для таких вопросов создан.
Пиздишь.
Это не так. С торрентов я качал мультики с такими картинками. Можно попробовать:
ffmpeg -i video -i audio -i mjpeg -map 0:v -map 0:a -map 1:v
где первый источник видео, второй аудио, третий картинка в mjpeg.
>ffmpeg -i Input.webm -i Img.png -map 0 -map 1 -c copy -c:v:1 png -disposition:v:1 attached_pic Out.mp4
Вот так. Но эта превьюшка только для системы работает, двощ все равно рандомный кадр выберет.
Спасибо анончики.
>двощ все равно рандомный кадр выберет
Ну это печально, как раз таки для двача хотел превьюшки ставить, а то весь смысл ролика теряется(
А почему превью этой вебм отличается на двух браузерах? В Firefox одно превью, в Edge другое.
Без понятия.
После многочисленных жалоб на скримеры, кодеры макабы накодили так, что превьюшка генерируется из случайного кадра видоса. Видимо из-за различий в алгоритме рандомайзера, в разных браузерах генерируется разная превьюшка.
Но это чисто предположение.
Эти картинки на сервере макабы генерятся, поехавшие https://2ch.su/s/thumb/3652226/17608648848370s.jpg
На изображения жёсткие, если без регистрации.
Пиздец попробовал aotuv vorbis и opus просто идет нахуй на любом битрейте. Опус по ощущением с каждым годом более говно, потому что гуглу важна скорость наверное, чем качество сжатия. Как уже писал раньше на 28к битрейта все кодировал и не было искажений, а сейчас на 64к присутствуют.
Он никак не меняется, пчел. Как и ворбис. Это с тобой чот.
Я не то имел в виду. И запутал вас. У меня вопрос в другом, а именно в кадрах этой вебм-ки, почему перевязанный Сэм Лейк в 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бит. Теперь нашёл субтитры которые 20 МЕГАБАЙТ! На один эпизод! Ебучий урод! У меня плеер вылетел от этой хуйни. Понарисовал какой-то хуйни! С таким рисованием проще было хардсаб сделать.
То кодеки были какие-то ебанутые х264 10бит.
Все давно перекодируют в hevc и даже av1 всего за 150-200мб за серию, на няше достаточно поискать. Да и надо совсем древний проц иметь, чтобы x264 10бит не тянул.
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Перекодируй в srt
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - https://nyaa.land/view/1276567
>Теперь нашёл субтитры которые 20 МЕГАБАЙТ!
Представляю как ты знатно охуеешь увидев субтитры на 600 метров (в несжатом виде)! Весь видеоряд этого видоса векторный и сделан из субтитров - nyaa.land/view/1276567
Не открывается ссылка.
А так? https://nyaa.si/view/1276567
magnet:?xt=urn:btih:84d291c384907202387314c2e6e43ea301db8fdf
Ща блять, я буду неизвестному хую палить свой айпи на двачах через ДХТ. Агабля.
Анимубляди должны страдать.
Никому ты не нужен, шиз.
Ребят, я начал разрабатывать очередной gui для ffmpeg. Может быть готово где-то через пол года (я говнокодер). Поддержите меня. Я сейчас читаю книгу по разработке графических интерфейсов. Программа будет похожа на boram, так как он мне больше всего нравился, но он не обновляется
Уже придумали за тебя в виде FFmpeg Batch AV Converter в котором есть буквально всё практически. Настолько, что этот гуи можно адаптировать под exe других прог, единственный косяк постоянный параметр -i
>FFmpeg Batch AV Converter
Не хочу вайн ставить для неё, там есть функция кроп в интерфейсе? На скринах не увидел. Мне эта фича в boram нравилась, но её блядь нигде нет, чтобы было так же удобно. Ну и минус конечно, что нет нормальной сборки под линукс
>Настолько, что этот гуи можно адаптировать под exe других прог
Что это значит вообще? Зачем это?
Не понял про что ты конкретно, но есть такое
Да, типа такого, но я немного по другому сделаю
Ну так и скажи тебе хочется заняться бессмысленным ненужным пердолингом, и больше некуда время тратить. На уровне челов, который в миллионный раз пилят фронтенд для yt-dlp. В avidemux тоже кроп есть через avisynth можно прям линии ставить как тебе надо, в xvid4psp тоже есть кроп.
Не нужно.
Мало ли что можно. Не значит что это нужно.
Сейчас анимубляди вперди всех жмут в AV1, который в моём "старом" (5 лет) телефоне железно не поддерживается. Но вроде он хотя бы существует и развивается, а не как х264 10бит мертвонерождённый.
Ну оно как минимум мне нужно, потому что boram нормально без ебли с устаревшими зависимостями не запускается, а все остальные мне не нравятся. Для себя я попердолиться не против, а там уже мне не особо важно, понадобится она кому-нибудь или нет. Ну и плюс будет какой-то опыт и проект. У меня в вузе средний проект выглядит как тудушник или календарь дней рождения
Ну короче спасибо всем за поддержку аноны, как всегда мощно обосрали
Без психической поддержки уже не может программу для себя написать?
Ты довел меня до слез
Борам конечно дело свое делал, но это ужасающая электронопараша, даже автор уже не хочет уже разбираться в своем говнокоде.
Автор в принципе прекратил активность на гитхабе. Может быть, он умер.
Там это, ваш ffmpeg протёк.
https://habr.com/ru/news/965518/
Если коротко, гугл находит слишком много уязвимостей, мы не успеваем их исправлять, а гугл через 90 дней выкладывает их в открытый доступ. Дайте деняк или прекратите искать уязвимости в нашем открытом коде, ежедневно проверяемом тысячами квалифицированных экспертов, всем же известно, что в СПО не может быть так много уязвимостей.
https://habr.com/ru/news/965518/
Если коротко, гугл находит слишком много уязвимостей, мы не успеваем их исправлять, а гугл через 90 дней выкладывает их в открытый доступ. Дайте деняк или прекратите искать уязвимости в нашем открытом коде, ежедневно проверяемом тысячами квалифицированных экспертов, всем же известно, что в СПО не может быть так много уязвимостей.
Какие нахрен уязвимости в оффлайновой программе? Или ффмпег сообщает гуглу о том как я шебм с неграми конвертирую часами?
>Там это, ваш ffmpeg протёк
>ИИ-система нашла баг в системе декодированием кодека LucasArts Smush, в частности первых 10–20 кадров Rebel Assault 2, игры 1995 года
ffmpeg библиотеки например в хроме и фурифоксе используются, ты открываешь видео, а оно крашит твой таб или даже весь браузер, норм тебе такое?
Гугл наверняка ffmpeg еще и для перекодирования видео на ютубе использует.
Дальше что? Че то не нравится, пишите с нуля свое, делайте форк, не ебет, это опенсорс. Че-то можете предложить? Сделайте коммит.
Ну челы правильно написали. Куча пидорах компаний, у которых обороты больше триллионов и не вложили даже копеечку, и абузят опенсорс.
>в оффлайновой программе
ffmpeg – это буквально пикрил
И че они сделают, если не поправят уязвимость? Затерпят.
У себя исправят и патчи зажмут.
Хоть кто-нибудь может объяснить мне феномен фиолетового выцветания видеозаписей с регистраторов.
Вероятно это плёнка ик-фильтра начинает терять свои свойства и пропускать ик-излучение.
Делаю вот так когда не могу найти подходящего мелкого релиза какого-нибудь сериала что бы закинуть в телефон и смотреть. Нормально или что-то ещё можно добавить? Главное быстро и мелко и достаточное качество.
Почему не hevc c bframes? Хотя я свою библиотеку в av1_nvenc с cqvbr 34 кодирую с bf 7 и кучей подстроек, либо c svt-av1 он тоже достаточно быстрый.
Шарящие аноны, можно ли одним только ffmpeg решить такую задачу?
Задача: поделить видео на части при существенной смене кадра. Есть видео, типа слайдшоу, с переменной длиной слайдов. Нужно порезать это видео по слайдам. Но картинка на каждом слайде статичная не полностью, примерно 80% экрана остаются неизменными. Общая длина видео - чуть больше десяти часов, количество слайдов - примерно тысяча. Руками это будет адски долго и мучительно делать.
Пока на ум приходит только вытащить фреймы, и найти таймкоды изменений сторонними решениями (можно и самому скрипт написать, несложно). Но это костыльно - сохранять больше двух миллионов фреймов как отдельные картинки. Для raw не хватит места, а жать каждый фрейм - сколько времени уйдёт на одно только это, и ведь потом их ещё перебирать.
Может есть более адекватное решение?
Задача: поделить видео на части при существенной смене кадра. Есть видео, типа слайдшоу, с переменной длиной слайдов. Нужно порезать это видео по слайдам. Но картинка на каждом слайде статичная не полностью, примерно 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 просто крашит при проигрывании везде на телефоне, на ПК не пробовал.
И мне надо чтобы оно 1 кадром было, хотя вроде это и так таково.
ffmpeg.exe -i videvo.mkv -i audivo.mka -i piccha.png -map 0 -map 1 -map 2 -c copy govno.mkv
Не понял реквест. Тебе нужно видео из статичной картинки в 1 FPS + звуковой дорожки в ААС, взятую из М4А файла без перекодирования?
Либо как написали ffmpeg нарезка по scene changes, threshhold выставлять можно вручную. Для scene changes также есть скрипты на питоне. Либо если просто вес видео снизить или чтото подобное до deduplication frame сделать.
Кодировать в 4:4:4 или 4:2:2
С какими настройками сжать .mov в .mp4 примерно в два раза по размеру файла, а лучше в три, потери допустимы, но хотелось бы сохранить детали. Исходные параметры mov - 720p, битрейт 1700, размер файла 1.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 появляется.
Можно что-то поправить, чтобы скачивание было с самого начала?
Вот можно скачать видео 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, увидел, затестил, охуенный. Спасибо за информацию, быстро перекодировал и по размеру видео лучше намного.
Для libsvtav1 нужно что то специфическое скачивать или хватит полного билда с гитхаба? У меня он нормально не хочет ничего кодировать, на выходе получается каша с нечитаемыми словами, на вп9 лучше получается.
Не нужно.
>на выходе получается каша с нечитаемыми словами
Ты бы показал что получается и написал как кодировал.
Уже поздно, дня через три, может четыре напишу.
Перегруженное говно устаревшее.
Согласен на андрюше своем кодирую видео через 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
А, да, у меня почему то не тот пост отобразился, на который ты ответил.
Сеолько ffmpeg должен весить? Вот есть у меня с гитхаба который весит 120мб, а есть на 86. Это почему так?
Прочитай информацию в том репозитории, откуда скачиваешь.
В консоль при запуске выводится информация о конфигурации, запусти два разных и посмотри разницу.
>должен весить
Нет какой-то твердой цифры, ты (или автор билда) при сборке задаешь набор библиотек которые войдут в билд. Я вот этот беру.
https://github.com/AnimMouse/ffmpeg-autobuild/releases
А есть какойто совсем маленький и компактный? Мне ток мп3 в вав массконвертить для одного bash скрипта надо.
Я не знаю, но думаю такое только самому собирать.
А если версии 10-20 летней давности? Или там другие команды уже?
Ну попробуй найди. В чем собственно проблема? Разве 110 Мб это так много?
Есть версия с вшитыми либами в каждый экзешник, а есть версия где либы отдельно от экзешников.
>Мне ток мп3 в вав массконвертить
Возьми какую нибудь lame и не ипи моск.
Моя сборка весит 47М, 20М после upx.
Если вырезать всё, кроме аудио, то будет намного меньше.
Но проще взять lame, как выше посоветовали.
Где такую версию надыбать?
А не пашет lame в баш скрипте, как только не крутил, хз почему. Скрипт правда нейронка писала. Но вот ффмпег пашет натолично. Я коверчу из мп3 в огг, ужимая сильнее, а огг с мп3 напрямую не дружит, ему вавку подавай.
Можно попробовать что-нибудь вроде
lame --decode --mp3input -t - - | oggenc -r --ignorelength -o output.ogg -
Нашел на диске версию ffmpeg, которая весит всего 151 кб. В папке аирдроида была. Справляется с конвертом в вавку наотлично, а большего от нее и не надо.
-c:v libx264 -preset ultrafast -qp 0 -c:a pcm_s16le output.mp4
Вот это же быстро и без артефактов?
Я так через жопу собираю видео. Сначала нарезаю кусочки вот таким образом, потом склеиваю их все вместе и уже кодирую со сжатием.
Вот это же быстро и без артефактов?
Я так через жопу собираю видео. Сначала нарезаю кусочки вот таким образом, потом склеиваю их все вместе и уже кодирую со сжатием.
Норм
Скорее всего это версия без встроеных либ, а либы откуда то из path подхватываются. Так что это по сути тот же тяжеловесный комбайн.
pcm_s16le заменить на flac или alac похуй. Иначе мп4 глючит.
Заморочился темой кодирования идеальной mp3. Делюсь наблюдениями.
Поскольку каждый человек слышит по своему, то вместо использования своей необъективной психоакустики, сделал программу, которая сравнивает два 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 может совсем мало отличаться от оригинала.
Поскольку каждый человек слышит по своему, то вместо использования своей необъективной психоакустики, сделал программу, которая сравнивает два 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 показал меньше попугаев, а значит он более качественный.
Единственное, что ты смог показать, это свое скудоумие.
Не забудьте только что ещё бразуер, ось, звуковуха и динамики тоже оптимизированы под человеческий слух и тоже далеко не весь диапазон передают.
ffmpeg.dll есть в папке аирдроида, но весит она тоже немного - 3 мб.
короче походу двачерский плеер меньше чем 2 фпс плохо поддерживает.
то есть надо например создать видео из статичной картинки и аудио, надо всё равно прописывать -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
то есть надо например создать видео из статичной картинки и аудио, надо всё равно прописывать -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
Скачал твой аирдроид, вот все файлы с ffmpeg в названии.
Все что я делал в 1 фпс из картинки нормально постилось и воспроизводилось. Не знаю о чем ты.
includeadb - у меня нет этих файлов в папке. И эксешних 100кбайтовый работает отдельно без проблем, безо всяких длл конвертит из мп3 в вав.
Ну ладно.
Можешь команду скинуть, у меня почему то не всегда работает. Или попробуй в моей 2 на 1 заменить. Хз может дело в чем то другом
Я делал так -
Анон предложил так, я проверил и это тоже работает -
видимо дело в отсутствии -movflags +faststart
я ожидал что сразу воспроизведётся а надо ждать пока всё прогрузится
А нет, дело в аудио. с m4a не работает превью а с aac да. если надо с m4a надо ставить framerate 2.
Решит я тут коллекцию всяких шебмочек пережать с двача. И внатуре совсем с ума что ли сошел тот кто эту мп4 делал. Просто удивительное рядом. Сравните размер до и после.
И размер коллекции вышел в 5 раз меньше, чем был, с незначительной потерей качества. Как же av1 ебет.
Можете пожалуйста прислать используемые вами команды?
Эм, я в хмедиа ковертил.
Кста при пережатии порнухи у меня больше разница выходит - до 10-20 раз меньше размер. Само собой по большей части из-за статичного фона в большинстве порнухи, а ав1 умеет сильно на этом экономить. Но и пережимаю все в 720р, но квантайзер выше делаю - 43.
пережми видрил
Ну вот тут да. У меня тоже несколько попалось, которые не ужимались или даже больше становились. Ну такие я фильтрую и оставляю старую мп4. Ну можно еще попариться и уменьшить фпс и разрешение.
Ой, чет тупанул и не с той папки файл автоматом вкинул. Норм ужалась она.
хм, а я shutter encoder использую, про эту прогу не знал, попробую может она лучше
Ваще по кайфу ужалось все.
А вот пример, где видеопоток даже больше вышел у ав1. Так что эту мп4 смысла пережимать нет.
И вот этот больше вышел. Ну тут похожу сложная сцена с этими масляными разводами на воде, вот и пережимается хуже. Но если квантайзер побольше поставить то может и пережмется норм.
-------->
Тут видно что видео уже сильно зашакалено. Ужать еще можно, но не на CRF 43 и это только добавит новых артефактов.
У тебя звук в говно превратился.
Для архива сгодится. А если не найдешь оригинал, то нейросетка восстановит.
Я на 50 сжимал, и у меня вышло больше. А ты как при 43 ужал?
Сжал в ав1. Чуете разницу? Чуете?
Были же раньше времена...
https://files.scene.org/view/demos/groups/farb-rausch/fr-030_candytron_final.zip
https://files.scene.org/view/demos/groups/farb-rausch/fr-030_candytron_final.zip
Чую. Мыльных шакалов много вылезло.
Вот на AVC качество, визуально без потерь - crf 18, шакалы на гране терпимости - crf 23. А как с этим дело обстоит у AV1?
>А ты как при 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
ещё минус 63кб
дальше только стоит менять variance-boost-strength=(2/3/4)
enable-qm=1:qm-min=(5/10)
nlmeans, ну и crf
в остальном всё равно придётся менять разрешение и аудио, дальше либо слишком долго ждать либо уже картинка кукольной будет
дальше только стоит менять 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 конвертнуть во что-то другое?
Скачал аудиокнигу, она в формате нескольких 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 очень много смотрят на маленьких экранах, в режимах картинки-в-картинки и всяких автоплейных карточках которые они суют не спрашивая.
Но кодировать там можно на отъебись, это так.
Тоже не, H.264 жирный. И сейчас уже есть клиенты которые H.264 не умеют, а VP9 умеют. Линуксы красноглазые в основном, но и аппаратные платформы встречаются.
Тут не какая-то бинарная задачка что одно лучше чем другое, а сложные поиски баланса между зрителями, траффиком, хранилищем и процессорным временем.
Но сейчас все чешут репу что делать с тремя кодеками в переходном состоянии, вполне вероятно что мы скоро придём либо к паре AV1+H.264, либо AV1+VP9, а третий помрёт. и начнём чесать репу что делать с H.266, AV2 и AVS3
У ВК Видео доклад был недавно. Видео вроде нет публично, но презентацию можешь полистать: https://vtconf.com/talks/7658d5759967410aa3def6cea5e00434/ там VP9 гасят по чуть-чуть например.
Какие параметры использовать на экстремально низких битрейтах? Например фильм 1.5-2 часа вжать в 40 мегов двача.
>Например фильм 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 ебет.
В дерьмовом режиме, еще и 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 занижать? а он и так низкий
исходник из 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 занижать? а он и так низкий
хотя ещё можно gop сделать выше, хоть 9999, но тогда перемотка будет страдать. ну и разрешение понизить
С видео вообще ничего делать не нужно, у тебя там и так битрейт 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).
Оригинальный файл с 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 в статике значения особо нет
сам opus если что 25.1 весит
Летучая мышь в треде, все в пещеры!
Как сделать изменение частоты кадров? Чтобы не константа, а плавно менялось, как результат какой-нибудь матфункции. Например, fps = 2t, где t это время и принадлежит [t1, t2].
Или посложнее функции. t2, например
Спасибо что продолжаешь веселить тред своими скудоумием и некомпетентностью.
Не за что.
>VBR вместо CBR.
C vbr больше размер выходит.
>crf 38 максимум
Жирновато выходит! Я эти ролики то смотрю раз с 10 лет, чисто в архив и пох.
>раз с 10 лет
легче удалить или на облако залить
Не легче, история как никак. И надо хранить, чтобы не забыть.
Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Не видел такой щедрости в нашем мухосранске.
Говорят сейчас можно заказать что угодно откуда угодно. Пиздят наверно.
Возможно не туда пишу. Хочу скачать вот https://www.youtube.com/watch?v=_bQ_u5mKLko это видео - но у него ограничение по возрасту стоит, ничего не помогает. Может кто-нибудь из вас его скачать и в тред в виде webm закинуть?
> Щас всего за тыщу за терабайт можно взять неплохие жесткие диски. За две тыщи за терабайт можно взять два диска. Бэкапишь между ними и хранишь там свой мусор сколько хочешь.
Шутишь?
Так ты не 1тб смотри, а минимум 4тб, там по 3к за 1тб. Если ты бохатый, то нормально. Если не бохатый, то милости прошу на авиту, бери вилку и чисти. Моё личное мнение, лучше два б/у диска с авиты чем один новый из магазина.
И придет говно нерабочее, дальше что?
Это значит что ты лох. Выбирай лучше. Я выбирал, покупал, нормально пришло.
Телепатией выбирать? А если посылку как джим керри доставят и продаван будет не при чем?
Правильно я понимаю, что при уменьшении изображения, метод супервыборки аналогичен методу свертки билинейным фильтром?
Лучший кодек, работайте, братья.
Есть аудиодорожка, она в несколько раз длиннее видеодорожки, есть гифка, она будет видеодорожкой по итогу. Я хочу, чтобы гифка была зациклена до конца аудиодорожки (гифка короче, опять же), но не занимала лишнее место одними и теми же кадрами при этом. Это вообще реально? Libsvtav1 желательно, нейронка не помогла.
Закажи.
Должно быть реально. Попробуй принудительно установить точную длину источника:
ffmpeg -i видео -i источник_аудио -to 00:11:22.500
Как рендерить видео в Reaper без потери качества?
Загружаю в рипер видос в формате mp4, скорость потока 2377 кб/с.
Редактирую
Рендерю в mp4. Разрешение оставляю оригинальное, качество выставляю 2500 кб/с - на выходе картинка какая-то зашакаленная по сравнению с оригиналом - словно глубина цвета меньше и картинка местами едва заметными квадратиками идёт.
Пробовал выставлять качество потока 5000, менять контейнер с h.264 на mpeg2, менять resample mode - никакого толка.
ЧЯДНТ?
Загружаю в рипер видос в формате 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
Во, заработало! Вроде ровно и хорошо нарезало.
Чёт я раньше качал что-то резать и там что-то не срослось. А сейчас прям залетело заебись.
Вопросы к шарящим в работе кодеков, в частности H265 (HEVC).
Провёл для себя небольшие сравнительные тесты, и выявил странности в функционировании пресетов. Суть:
Кодирую 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. В чём тут тогда логика, и как пользователю оперировать с данными параметрами?
Алсо, каким образом можно численно проанализировать полученные видео на качество, в сравнении с оригиналом?
Провёл для себя небольшие сравнительные тесты, и выявил странности в функционировании пресетов. Суть:
Кодирую 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.
Вряд ли открыл что-то новое, кроме как для себя. Вроде как мои результаты в целом соответствуют бенчмаркам энтузиастов.
>При этом, совершенно не понятна взаимосвязь 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
>что надо неделю ждать
Нет такого давно. Разве что ты нулевой пресет выставил.
FFMetrics
Да, я скорее всего 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, и отключение функции позволяет производителям формально избежать дополнительных платежей.
21.11.2025 11:12 (MSK)
Компании HP и Dell в ряде современных ноутбуков намеренно отключили аппаратное декодирование видео с использованием видеокодека HEVC (H.265), хотя используемые процессоры AMD и Intel технически поддерживают эту возможность. HP упоминает об отключении аппаратного ускорения HEVC в спецификациях некоторых моделей ProBook и EliteBook. У Dell ситуация менее прозрачная - официальные спецификации не содержат предупреждений, однако служба поддержки компании подтверждает, что HEVC недоступен на базовых конфигурациях без дискретной графики, 4K-экрана или пакета мультимедийных лицензий.
Обе компании отказались объяснять причины такого решения. Предполагается, что отключение вызвано стремлением сократить лицензионные расходы: с января увеличиваются лицензионные отчисления за каждое устройство с поддержкой HEVC, и отключение функции позволяет производителям формально избежать дополнительных платежей.
Че там av2/amv уже скомпилил тестил ктото? 50% к сжатию av1 уже имбово звучит, еще svt-av1 4.0.1 вышла, но по сути новая версия это просто все функции интузиастов с svt-av1-psy спиздили в мэйнлайн.
Какая самая лешевая видеокарта для апаратного кодирования AV1, мне нужно, аниме, фильмы, сериалы перегнать в него для жкономии места. Не на проце тоде неплозо идет, но когда я пробовал в hevc на вилюхе мне там под тысячу кадров в секунду делала, а на проце в ав1 под 200-300 только.
>200-300 только
Это значит что за сутки ты почти год своего аниме перемолотишь.
Нахуй тебе быстрее?
Пока видеокарту тебе доставлять будут ты натранскодишь больше времени контента чем тебе жить останется.
> FFmpeg Batch AV Converter
Не зря почитал тредю, удобная программа, как раз искал способ конвертировать много файлов за раз
И чот бегло поглядел по пресетам видео, не увидел в списке ваш новомодный AV1, такой же непонятный и неуловимый как для аудио DSD вроде бы, со странной частотой дискретизации в 1.5 МГц
Не зря почитал тредю, удобная программа, как раз искал способ конвертировать много файлов за раз
И чот бегло поглядел по пресетам видео, не увидел в списке ваш новомодный AV1, такой же непонятный и неуловимый как для аудио DSD вроде бы, со странной частотой дискретизации в 1.5 МГц
А чего ShotCut с настройками по умолчанию для HEVC сжимает сильнее, чем HEVC из FFMpeg?
Ой чот мне не нравится, что на выходе 900 МБ вместо приятных 200МБ, ой фу ваш ffmpeg
Ой чот мне не нравится, что на выходе 900 МБ вместо приятных 200МБ, ой фу ваш ffmpeg
>crf=28 vs crf 23
>а чего сжимает сильнее
Это сраказм?
Нет, я настроек не знаю и потому приходится просто экспериментировать чтобы и качество не всратое и вес небольшой, в ShotCut настроек по умолчанию за глаза, но я не нашёл как сразу несколько файлов пережать
ffmpeg умеет при компрессии сохранять все аудиодорожки, а не сливать всё в одну?
ффмпег всё умеет.
Умеет, но если у тебя остаётся всего одна дорожка, то как-то так:
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 часа в сутки, то есть студийная техника, которая стоит как автомобиль.
Зачем вы тут ковыряетесь, если профессионалы сто лет назад выяснили, сколько битрейта хватит на CD Quality?
Я flac, если он есть, на диски пишу, даже 700 1000 бит рейт за глаза
Есть и старые диски с качеством как на картинке, конечно звучит отлично, но место не резиновое
Значит мне не показалось, получается ситуация как с рендерингом на видео и процессором в каком нибудь vray
Буду экспериментировать дальше, видяха конечно быстрее, даже процессора 3950
Ну шутка-то в том, что даже 128 кб/с, который пафосно называли неотличимым от оригинала, на самом деле не годился, а тут WMA в 64 кб/с, который булькал и дзынькал ничуть не меньше, чем MP3 первых лет на таком же битрейте. Только LAME потом годами оптимизировали, чтобы артефакты как можно лучше скрывать на типичных звуках, а WMA вскоре стал не слишком нужным. Нахальство Microsoft, которая тогда пыталась подмять под себя весь мир и все индустрии сразу, не знало границ.
В интерфейсе Windows Media Player для сохранения музыки с дисков уже скромнее были и рекомендовали 128 килобит.
>FFmpeg Batch AV Converter
Надо попробовать. Есть ещё Shutter Encoder, тоже надстройка над ffmpeg
>Какая самая лешевая видеокарта для апаратного кодирования AV1, мне нужно, аниме, фильмы, сериалы перегнать в него для жкономии места.
Думаешь видеокарта будет дешевле ещё одного жёсткого диска?
Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Ты не понимаешь, что в сжатии с потерями важен не новый или старый кодек, а формулировка задачи, выбор критериев, которым должны соответствовать результаты (объём, качество, максимальная скорость чтения или передачи и так далее). Если ты не знаешь, что ты хочешь получить, то просто зря потратишь время и электричество.
Для того, чтобы сделать «точно так же, но меньше объёмом за счёт нового кодека», нужно сначала определить, сколько это «точно так же», сколько в файле «качества». Это, в общем, не решаемая задача. Либо мы можем попробовать использовать сам анализатор кодировщика, чтобы оценивать сложность данных по сравнению с «типичными» (в современных кодеках проделана такая работа), но тогда надо как-то игнорировать артефакты сжатия и фильтрации (добавление шума), не считать их полезными данными, в отличие от оригинальных деталей изображения (а как их отличишь?). Либо можно в лоб взять большое число отрывков из разных мест, посчитать какую-то визуальную метрику для оригинала, перекодировать с какими-то настройками, посчитать метрику для результата, и корректировать настройки, пока не не станет достаточно близко. Это и будет «примерно такое же качество» (но только для этой метрики). Но вообще это всё глупости, и для каждого следующего перекодирования надо потратить не меньше времени на оценку заметности ухудшений, чем тратил автор предыдущего. Ты будешь сидеть и подбирать параметры для каждого фильма? Сомневаюсь.
Вообще, вся эта затея глупа ещё и потому, что о перекодировании начинают думать, когда результат становится на порядок или хотя бы в несколько раз меньше оригинала. Что-то мне подсказывает, что пережимать фильмы до состояния экранки, зато маленькой, ты всё-таки не готов. А от ужатия с новыми настройками или кодеками на несколько процентов при прочих равных может выиграть только гигантский архив вроде YouTube (где эти проценты превращаются в ящики, полные жёстких дисков, на которых можно сэкономить), которому есть выгода потратиться на работу. У тебя от освобождения 10% диска ситуация кардинально не поменяется. Так что либо займись разбором и уборкой, либо прими, что имеющиеся варианты тебя устраивают, важны, будут храниться, и расширяй объём хранения.
>что ты хочешь получить, то просто зря потратишь время и электричество.
Классика жанра же!
> Ты мне напоминаешь человека, который когда-то отсканировал семейные фото в 1024×768 (потому что это же ПОЛНЫЙ ЭКРАН МАКСИМАЛЬНОЕ КАЧЕСТВО БОЛЬШЕ НЕ ПОНАДОБИТСЯ) и сделал АВТОУРОВНИ, чтобы на мониторе разглядеть тёмные места можно было. Вот, а теперь эти файлы как-то уже совсем стыдно выглядят.
Если человек знал что хотел, то результат своим требованиям в тот момент полностью соответствовал. А современные мониторы и объёмы хранилищ просто в них не входили.
Ну так HEVC - лицензируемая параша, и с каждого устройства с его аппаратной поддержкой надо уплатить НОЛОГ за воздух, иначе суды, штрафы, санкции, гроб, кладбище. Поэтому у VVC-параши нет будущего, везде будет AV-1 (и H264).
Ну и чо теперь делать? У меня карта может только 265 кодировать, а ваш ав нет, ещё и проигрывателю плугин нужен
Ну его нахуй
Если тебе в 1-ю очередь важно качество, то любые аппаратные кодеры - это кал, т.к. производят немало артефактов.
Как этим пользоваться? Точнее так, как это должно работать?
Чего я ожидаю: я указываю ему начальное и конечное время из некого видео и затем при запуске сжатия он заодно его и порежет
Чего получается на выходе: жмёт и обрезает
На кнопку нажимал, он ошибку выдаёт
Чего я ожидаю: я указываю ему начальное и конечное время из некого видео и затем при запуске сжатия он заодно его и порежет
Чего получается на выходе: жмёт и обрезает
На кнопку нажимал, он ошибку выдаёт
Разобрался проблема была в том, что он не может или не хочет перезаписывать файл, так как я сохранял туда же и с тем же именем уже обрезанный файл есть в этом смысл, так как он сначала делает пустышку-заготовку с именем, а в процессе туда инфу заливает
>ой фу ваш ffmpeg
Ты в курсе, что в твоем шорткат тоже ffmpeg?
Да, в нём настройки по умолчанию дают результат, который меня устраивает, на данный момент я уже подобрал параметры, так что проблем нету
так обычно и происходит это не способ плохой это просто ты не разобрался. (личное моё наблюдение) все способы которые обещают быстрый однокнопочный результат - компромиссные и уступают по качеству. а если хочешь лучше - надо разбираться. но в ffmpeg хорошо то что он универсален, один раз надо только разобраться и потом всю жизнь можно пользоваться в отличии от того чтобы прыгать от проге к проге и каждый раз заново учится с ней работать
Добавь -y в команду, тогда будет перезаписывать файл.
При старте обучения всегда идёт копирование рабочего примера, ещё лучше, если есть пример под конкретную задачу, а потом уже идёт рост вширь с изучением тонкостей
Я даже теорию придумал, два типа обучения
Обучение копированием - быстро, но нет гарантии запоминания
Обучение через открытие - некое самостоятельное исследование с набором небольших знаний, изучение всяких источников и потом на основе этого само открытие - долгий, неопределённый по затратам времени процесс, но результат запоминается навсегда
Попробую
охуительное открытие, зайди в патентное
хорошо так и оставлю 1.2 гб за 6 минутную серию аниме в 1080п, не ну что зачем мне экономить место и возиться с этиси кодеками и настройка, просто увеличу место, у меня же корпус бесконечный и три блока питания в каждом по 20 сата портов.
Есть видеодорожка анимации с ютуба, хочу ровно по кадрам вырезать одну её часть. В картинки извлечь получилось, нужный диапазон кадров знаю. Хочу сделать это без перекодирования — MP4 (libdav1d) —> AVIF (libdav1d). Это реально?
>ss флаг в FFmpeg юзай и всё
Забейте на >
MP4 это видеоконтейнер, AVIF это формат хранения изображений. Очевидно нет, нельзя.
что думаешь не стоит?
там еще ютуба есть, но там поменьше около ста гигов, и половина скачана как раз в ав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 символов. Чтобы уж точно было интересно разгадывать загадку-шизофазию, экструдированную из твоего пропитого стекломоем рта.
Эх, а я надеялся, что мне ответят умные люди, которые разбираются в тонкостях сжатия 265. Промолчали бы что ли, тут вроде бы не ваш личный бложик, где вы ЧСВ тешите
Либо ты даёшь нормальные вводные, с хотя бы двумя этими разными файлами, либо идёшь нахуй как жирное дерьмо
ты вопрос сначала нормально задай, а потом обижайся
мы откуда знаем, че ты там сжимаешь
>разные файлы
>количестве кадров
такой ответ устроит? или ты не можкшь связать две взаимосвязанные вещи?
Альянс AOMedia начал разработку нового звукового кодека OAC на базе Opus Аноним (Microsoft Windows 10: Firefox based) 23/02/26 Пнд 03:23:50 #367 №3697535
Организация Alliance for Open Media, известная по созданию видеоформатов AV1 и AV2, а также формата изображений AVIF, приступила к созданию нового открытого звукового кодека. Проект получил название Open Audio Codec или сокращенно OAC. Данная технология позиционируется как прямое развитие популярного формата Opus от организации Xiph.Org. В качестве эталонной реализации разработчики представили библиотеку liboac, которая базируется на исходном коде libopus и распространяется под свободной лицензией BSD.
Главная цель OAC заключается в качественной передаче звука и речи через интернет. Кодек отлично подходит для интерактивных задач, включая голосовую связь, видеоконференции, игровые чаты и удаленные музыкальные трансляции. Формат легко масштабируется, позволяя сжимать как высококачественную стереомузыку с высоким битрейтом, так и обычный голос в условиях ограниченной пропускной способности сети.
На данный момент проект находится на ранней стадии разработки. Создаваемый библиотекой битовый поток пока не рекомендуется использовать для распространения файлов, поскольку он содержит отладочную информацию и временно не поддерживает перемотку. Технические характеристики OAC во многом наследуют базовые возможности Opus версии 1.5. Новый кодек поддерживает битрейт от 6 до 510 килобит в секунду, частоту дискретизации от 8 до 48 килогерц и продолжительность кадров от 2.5 до 60 миллисекунд. Кроме того, реализована поддержка постоянного и переменного битрейта, работа с количеством каналов вплоть до 255, а также возможность кодирования как узкополосного, так и широкополосного звука. Разработчики предусмотрели алгоритмы восстановления звукового потока при потере пакетов данных и поддержку вычислений с плавающей и фиксированной запятой.
https://www.opennet.ru/opennews/art.shtml?num=64852
Главная цель 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, да сейчас значимая часть выходит, а задирать битрейт чтобы скомпенсировать потери на ресэмпле - не шибко много наэкономишь. Когда я это решал еще и поддержка опуса была далеко не везде.
>задирать битрейт чтобы скомпенсировать потери на ресэмпле
Шо за хуйню я читаю. Во-первых, битрейт ортогонален сэмплрейту, потому что кодек всё делает в спектральной области. Если он, условно, видит две синусоиды, он их кодирует как две синусоиды независимо от того, в каком они сэмплрейте. Сэмплрейт в спектральной области это лишь масштабирующий коэффициент на шкале частот. Во-вторых, ресэмпл ты один хуй делаешь, но только если ты делаешь его при кодировании, то ты делаешь его один раз и без спешки, а если ты делаешь его при прослушивании, то ты его делаешь при каждом прослушивании и в риал тайме, т.е. более быстрыми = более грубыми алгоримами.
Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями. Невыжно как он ее воспринимает теперь - она уже искажена.
> ресэмпл ты один хуй делаешь
Схуя ли?
Значение имеет не эта менюшка, а какой кварц к ЦАПу припаян. ЦАПы под капотом тоже умеют делать ресэмплинг.
>Кодек получает синсоиду на сжатие после ресэмпла - а значит уже с потерями.
Ресэмплинг в теории можно сделать сколь угодно близким к идеалу. А на практике — настолько близким, чтобы выход алгоритма кодирования совпадал для обоих вариантов бит в бит. И ровно для этого и имеет смысл делать ресэмплинг не на лету, а заранее.
при слепых тестах 99% испытуемых считают 128кб vbr opus - практически неотличимым от flac оригинала / прозрачным. даже если повышать битрейт до 192 или 256, в итоге файл всё равно будет весить меньше аналогов.
а при глухих тестах?
Вопрос не по теме треда, но спрошу здесь.
Вот на ютубе есть функция ускорения видео. При этом, звук не становится хай-питч, как при ускорении в обычном плеере. Собственно, а можно ли в MPC или ином видеоплеере добавить такую же функцию? По какому принципу это вообще реализовано?
Вот на ютубе есть функция ускорения видео. При этом, звук не становится хай-питч, как при ускорении в обычном плеере. Собственно, а можно ли в MPC или ином видеоплеере добавить такую же функцию? По какому принципу это вообще реализовано?
View - Options - Audio - Audio renderer - MPC Audio Renderer
>По какому принципу это вообще реализовано?
Оконное преобразование Фурье. Сначала прямое, потом делают окна шире/реже или чаще/уже, и обратное.
Хм, спасибо! Оказалось, у меня была настолько древняя версия MPC, что там такого ещё не было. Накатил свежий кодек-пак с MPC, теперь заебца.
Понятно. Не для моих жидких мозгов.
Да ничё сложного, спектрограммы видел когда-нибудь? Вот делают сначала из аудиодорожки спектрограмму, потом сжимают её во времени или растягивают, чтобы частоты при этом никуда не съезжали, потом обратно превращают в звук.
>жать ли музяку для экономии места в опус. Ну и ответ поэтому вышел - нет, потому что
Потому что опус не для этого, дегенерат.
Он именно для речи и для передачи по сети задуман и заточен, поэтому там никаким тюнингом ни под хранение, ни под музыкальную индустрию и не пахнет. Зато почти реалтайм – а тебе это на кой чёрт?
Ну и этот новый опус ровно туда же двигается.
А что по твоему лучше подходит для музыки? aac? если конечно не flac
Живые музыканты с настоящими инструментами, только так и никак иначе.
Для хранения – вообще что хочешь.
Любая эзотерическая хуйня, тебе же не надо чтобы кто-то кроме тебя это умел воспроизводить.
Vorbis наверное, но хуй знает точно. Я бы ёбнул пару треков конкретно твоих хотя бы в Vorbis, AAC, AC3, AVS2 и посмотрел.
Помимо AAC у MPEG ещё дохуя разных кодеков ебал в рот их номенклатуру да и у самого AAC уровней тоже хватает.
Аас тоже кста.
Time stretch.
А если электронная музыка?
> Потому что опус не для этого, дегенерат.
Ты бы не охладил траханье, углепластик?
На их собственном оффсайте
> 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.
Дальше что?
Opus — это свободный аудиокодек с высокой степенью сжатия, созданный для универсального использования в интернете.
История:
Разработан в 2012 году организацией IETF (Инженерный совет интернета) в результате слияния двух кодеков: SILK (от Skype) для речи и CELT (от Xiph.Org) для музыки. Это объединение позволило ему одинаково хорошо работать с любым типом звука. В 2017 году он стал обязательным стандартом для браузеров и WebRTC (технологии потоковой передачи).
Предназначение (ключевые особенности):
1. Универсальность: Заменяет сразу несколько кодеков (MP3, AAC, Speex). Одинаково эффективно сжимает как человеческий голос (от 6 кбит/с), так и сложную музыку (до 510 кбит/с).
2. Низкая задержка: Идеален для стриминга, видеозвонков и онлайн-игр, так как имеет минимальную задержку при кодировании.
3. Открытость и бесплатность: В отличие от MP3 или AAC, за его использование не нужно платить лицензионные отчисления (патенты), поэтому он широко поддерживается всеми браузерами и приложениями (Discord, Spotify, YouTube).
История:
Разработан в 2012 году организацией IETF (Инженерный совет интернета) в результате слияния двух кодеков: SILK (от Skype) для речи и CELT (от Xiph.Org) для музыки. Это объединение позволило ему одинаково хорошо работать с любым типом звука. В 2017 году он стал обязательным стандартом для браузеров и WebRTC (технологии потоковой передачи).
Предназначение (ключевые особенности):
1. Универсальность: Заменяет сразу несколько кодеков (MP3, AAC, Speex). Одинаково эффективно сжимает как человеческий голос (от 6 кбит/с), так и сложную музыку (до 510 кбит/с).
2. Низкая задержка: Идеален для стриминга, видеозвонков и онлайн-игр, так как имеет минимальную задержку при кодировании.
3. Открытость и бесплатность: В отличие от MP3 или AAC, за его использование не нужно платить лицензионные отчисления (патенты), поэтому он широко поддерживается всеми браузерами и приложениями (Discord, Spotify, YouTube).
>Ты бы не охладил траханье, углепластик?
Какой слог!
Дауны, о чём вы спорите?
По аудио форматам всё давно разжёвано:
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.
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
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
Если говорить про битрейты 320+, то они и так дают чрезмерное качество, не отличимое от 192-256. Когда на 500 кбит/с срезаются 20 кГц - это и есть шиза. На таком битрейте нет проблемы сохранить 20-22 кГц. Да, разницы на слух всё-равно не будет, но тем не менее. Если битрейт не далёк от лосося, то и смысла ужиматься по частотам нет никакого. По статусу не положено, как говорится. Качество и так запредельное.
>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кГц, а завтра чтобы на спектрограмме рисовались хуи.
Вот у меня лежат два файла, выкачанные с ютуба. Кодек, разумеется, OPUS.
Размер на диске 8 и 9 мб
Они же во FLAC занимают 21 и 25 мб.
Размер на диске 8 и 9 мб
Они же во FLAC занимают 21 и 25 мб.
Да вы тут все шизики. Лично я про форматы с потерями забыл ещё в 2010 году, когда со стипендии купил себе винт аж на 1 ТБ. Тогда же перестал записывать на двд и сд. С тех пор вся музыка во флаке, теперь даже на смартфоне (256 ГБ + 1 ТБ сд карта). Сейчас у меня вся фонотека (80+% которой я практически не слушаю) - жалкие 1.8 ТБ, при доступных 14 ТБ. В подтверждение того, что я давно практикующий меломан, прилагаю счётчик фубара за последние ~15 лет.
В общем, в 2026 году не вижу ни малейшего смысла хранить музыку в лосси форматах. Разве что вы совсем уж отмороженные шизики-архиваторы, которым надо скачать и хранить ВСЮ музыку, 99+% которой вы ни разу не прослушаете.
Кстати, фильмы и сериалы на компе давно не храню, потому что за годы осознал, что повторно ничего не пересматриваю. Посему - скачал-посмотрел-удалил. Храню только музыку (концертники), но объём тоже смешной, ~800 ГБ.
Двачаю, вон на двух файлах выше - так везде, разница ну в три раза. Размер станет заметен, если пытаешься сохранить всю музыку мира.
> практикующий меломан
> меньше часа в сутки
А бэкап? Когда он у тебя сдохнет - локти будешь кусать. У меня коллекция в 2х бэкапах.
У меня во флак только своя музыка, которую я написал, остальное - мп3, аас, огг и т.д.
Audio: Opus 48000Hz stereo 3072kbps
Ты че дурак? Ужми в 96 кб (уже прозрачное качество), и там не в 3 будет а в сто.
А, не, 332 kb/s. Чет плеер гонит мой. Но все равно 96 кб\с уже в 3 раза меньше, чем 320. Итого выйдет раз в 10 сохранение размера с таким же качеством.
Так что терабайт или 100гб? Ощутимо? Еще как.
Тебе сколько лет, мальчик? С годами всякое дерьмо начинается (работа, семья). Последние 8-10 лет если удаётся вечерком хоть час послушать музыку дома, сидя перед компом - это прям в диковинку. А так - смартфон+автомобиль.
Нашёл кому рассказывать. В шкафу винтов на ~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кГц как физиологический потолок слуха.
По сути верно, но с уточнением, что этот переходный процесс возникнет даже до динамика, ещё на выходе ЦАПа.
Не нужно. А вот идеальную ступеньку — нужно, потому что у идеальной ступеньки бесконечно широкий спектр.
Странно, а научные исследования, физика и тесты говорят об обратном.
Да даже на мелких, но хороших, динамиках слышу что 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 раз видел
Чё то вы так opus и вообще все форматы засрали. Как будто ничего лучше musepack и не придумали
Только собственные личные ансамбли, оркестры и композиторы играющие оригинальную музыку и любые высококлассные каверы в любом стиле по твоей просьбе, только хардкор.
Ну и тёплый, ламповый винил.
Потому что носятся со своей психоакустикой, как дурни.
ну если лично я разницы не слышу, то стоит ли трястись? 256vbr опус мне за глаза. сколько пытался услышать разницу с флаком - не услышал. а вы сами решайте. musepack, vorbis, mp3 = устарели, форматы зомби. сейчас актуальны и обновляются только aac и opus, всё остальное lossless (а там только flac, ну и разве что WavPack и Monkey's но нахуя)
Ну тупые, не то что некомпетентное диванное шизло с магическим мышлением вроде тебя.
> Только собственные личные ансамбли, оркестры
Заодно можно почувствовать себя худруком
Сравнил. Разницы практически не слышу. Но как будто она есть. Видимо нужна топ аппаратура, чтобы понять.
>Ты не понимаешь, как кодеки работают. Они сперва переводят всё в частоты, потом сжимают. И им гребёнка проще, потому что в ней меньше частот. То, что она для тебя более сложно выглядит, это только следствие твоего невежества.
Ну вот я сжал во флак, оригинал и фильтровку. Фильтровка ужалась чуть хуже.
test это сгенерированные одиночные семплы 32767 через каждые четверть секунды
Вижу высокие частоты. Это для того чтобы плебеи их не слышали или для того что раз аппаратура говно, то нечаго наворачивать частот?
>Ну вот я сжал во флак
Я про lossy-кодеки говорил. Надо было это уточнить, да. FLAC не использует психоакустическую модель и не раскладывает звук на частоты.
Щас проверил диапазон частот, что я слышу своим слухом, на своей говноаппаратуре. Получилось примерно от 15 Гц, до 18000 Гц. У может до 19000 - что то там еле-еле меняется на пределе, если двигать головой перед динамиками.
Вывод такой. Что может что нибудь особенное будет ощущаться на >20кГц, но не на моей аппаратуре, точно.
Вывод такой. Что может что нибудь особенное будет ощущаться на >20кГц, но не на моей аппаратуре, точно.
Если у тебя есть телефон, поставь на него Spectroid и посмотри спектр с микрофона, играя на колонки 21кГц (сэмплрейт поставь >48кГц, естественно). Увидишь, что твой динамик-пищалка эту частоту прекрасно играет, телефон её прекрасно слышит, а ты её не слышишь просто.
>>48кГц
в смысле, >=48кГц, больше или равно
вы ёбаные летучие мыщи что ли. БОЛЬШЕ 20КГЦ ЧЕЛОВЕК НЕ ВОСПРИНИМАЕТ
А если лобные доли сформировались, то выше 16КГЦ
ВРЁТИИ, Я ТАК ПРИМЕРНО ПРОЧУВСТВОВАЛ
мимо диванное шизло с магическим мышлением
Вообще, то что осознанно не слышишь те частоты не значит что не воспринимаешь их совсем.
Попробуй вместо синусоиды музыку послушать в полном спектре и в обрезанном, скорее всего вслепую спокойно отличишь.
То же самое со светом, например. Близкие к видимому спектру ультрафиолет и инфракрасный ты не видишь, но от первого быстро глаза начинают болеть, а второй воспринимается как температура. Т.е. цвета ты не отличаешь, но организм на них реагирует.
Есть один фильм в мкв, я из него достал одну дрожку нужную мне, потом остальные удалил, потом эту вшил обратно с перекодировкой в другой формат. На пк все работает как и хотелось. Телек лг 55олед позапрошлогодний вообще отказываетс яфайл открывать.
Я в этих вопросах нуб, выручай анон. и что опять с капчей из под куклы не грузится
Я в этих вопросах нуб, выручай анон. и что опять с капчей из под куклы не грузится
Ты б хотя бы 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.
Пересобери mkvmerge. ffmpeg не очень хорошо работает с мкв.
Я вот не могу понять, а можно ffmpeg'ом увеличить fps в 2 раза? Чтобы кадры не тупо дублировались, а именно что генерировались новые кадры, как "среднее" между двумя оригинальными кадрами. Для более плавной картинки.
minterpolate фильтр, но он медленный.
Спасибо.
В общем анон был прав, одного фымпега мало, достал нужную дорожку мквтул, пережал фымпегом, тзасунул обратно с удаление не нужных мквтул. Все ок. Спасибо за наводку.
Анончик, я в экстазе от этого дрянья! Попробовал кусочек старого концерта 25 фпс улучшить до 50 фпс, эффект фантастический. Будто проход в 4-е измерение.
Собственно, ещё вопрос, какие параметры данного фильтра дают максимальное качество? У меня сейчас вот так:
>minterpolate=fps=50:mi_mode=mci:mc_mode=aobmc:me_mode=bidir:vsbmc=1
Вкатывайся в ComfyUI если хочешь увидеть реально мощный улучшайзинг. Там можно понаставить разных нейроночек, которые днями будут ебать твою видеокарту на 100%, генерируя по кадру в 10 минут, зато результат - чистая магия. Есть и уплавнялки, и апскейлы, и фильтры, и т.д.
Для этого есть SVP Pro + TensorRT RIFE.
>можно понаставить разных нейроночек, которые днями будут ебать твою видеокарту на 100%, генерируя по кадру в 10 минут, зато результат - чистая магия
С моей гтх950 с 2 ГБ памяти единственная "магия", которую выдадут нейронки - посыл нахуй.
Богачей не спрашивали.
Поясните, а если у исходника 23.976 фпс, то какое значение правильнее выбрать для интерполяции в 2 раза, 47.952, 48 или 50 фпс? Чтобы корректно воспроизводилось разными плеерами, в т.ч. разношёрстными ТВ/медиа-боксами.
Алсо, если я сделаю 47.952 фпс и загружу на ютуб, то сохранится ли данное значение, или ютуб сам изменит фреймрейт до некого стандартного значения, типа 24, 25, 50 фпс?
Нахуя вообще эти 23.976 фпс в 2026 году? Свежий блюрей! Это же наследие со времён аналогового NTSC телевидения и киноплёнки, вызванное измерениями всего и вся лаптями в имперской системе. Почему от этого бессмысленного древнего кала до сих пор не отказались? Неужели аппаратным BD плеерам по сей день нужно именно 23.976 фпс?
Алсо, если я сделаю 47.952 фпс и загружу на ютуб, то сохранится ли данное значение, или ютуб сам изменит фреймрейт до некого стандартного значения, типа 24, 25, 50 фпс?
Нахуя вообще эти 23.976 фпс в 2026 году? Свежий блюрей! Это же наследие со времён аналогового NTSC телевидения и киноплёнки, вызванное измерениями всего и вся лаптями в имперской системе. Почему от этого бессмысленного древнего кала до сих пор не отказались? Неужели аппаратным BD плеерам по сей день нужно именно 23.976 фпс?
Сейчас бы стандарты 2026 года обсудить сидя на Windows 7.
СТРОГО умножаешь fps исходника на 2 (и пересчитываешь кадры, чтобы было ровно в 2N а не 2N-1). Проверяешь время последнего кадра в соснольке.
Это моя боль, чуть шаг в сторону --- или индексация ломается, или звук с видео начинают расходиться.
Если не уверен и фпс является постоянным, а не вэриэбл, можешь попробовать перед интерполейтом сделать это:
-vf "setpts=(24000/1001)/24*PTS, fps=24, [твои фильтры]" -af "atempo=24 / (24000/1001)"
Вместо 23.976, что является просто округлением, лучше использовать математически верное (24000/1001).
Это увеличит фпс с практически незаметным ускорением и не добавит новых кадров.
Собственно, весь контент для ТВ в 23.976 (24000/1001) или 29.970 (30000/1001) фпс это замедленные 24 или 30 фпс.
Да, fps фильтр после setpts обязателен, т.к. без него в старых версиях ffmpeg значение фпс останется прежним (23.976 в данном случае), а в новых версиях из-за бага фпс вообще сбрасывается на дефолтные 25, что создаст новые дубликаты кадров.
>Сейчас бы стандарты 2026 года обсудить сидя на Windows 7
Поехавший? Между NTSC и вин7 аж 56 лет.
Последние NTSC ТВ-передатчики в СШП и других странах были отключены как раз в 2009-2012 годах, когда вышла вин7. Им на замену пришло цифровое HD вещание, которому пофигу на фпс.
Тем не менее, на дворе 2026 год, а 23.976 кадров так и остались "индустриальным стандартом". Просто потому что.
Вот и я стремаюсь рассинхрона с аудио при таких манипуляциях.
Спасибо, буду пробовать.
>-af "atempo=24 / (24000/1001)"
Не понятно, как устроен и как работает этот фильтр. Так что по аудио есть вопросы, которые надо анализировать экспериментально.
>Не понятно, как устроен и как работает этот фильтр.
Так как изменение фпс происходит путем изменения таймстампов и ускорения, то то же самое нужно проделать с аудио чтобы избежать рассинхрона - ускорить его.
Не, я о том, что если мы ускоряем/замедляем аудио даже на мизерное значение, необходимо применять time stretching. Делает ли именно это или что-то иное данный фильтр - дока ффпмега молчит.
Питч остается прежним.
Можешь сам убедиться: ffplay -i aud.mp3 -af "atempo=2"
Понятно, спасибо!
ав1 иногда превращает кожу в замыленный пластик, это можно как-то пофиксить? пробовал менять crf, tune, enable-tf, enable-cdef, включал/отключал грейн и матрицы квантования, но ниче не работает.
1. оригинал
2. ав1 с crf10 и preset 6
3. x265 crf 18 preset medium просто для сравнения
1. оригинал
2. ав1 с crf10 и preset 6
3. x265 crf 18 preset medium просто для сравнения
>-af "atempo=24 / (24000/1001)"
Полная хуйня, типичный совет от нейрослопа.
24000/10001 = 23.9760239760..., в то время как в видео прописано 23.976, и именно это значение используется, все кадры расставлены кратно ему. Как там передаётся в NTSC не имеет значения --- после всех перекодировок и обрезаний в цифре все кадры и все аудиодорожки выровнены именно по 23.976.
И сейчас ты, конечно, принесешь примеры таких видео? А, впрочем, даже если и сможешь, то я просто скажу что и ты, и тот кто делал видос - криворукие долбоебы пытающиеся зачем-то спорить с общеизвестными фактами, а большинство видео имеют математически правильный 24000/1001 фпс хотя соглашусь, что изредка, может, и встречаются кривые поделия, ЕМНИП.
К слову, в самом ffmpeg для fps фильтра есть константы ntsc_film (24000/1001) и ntsc (30000/1001).
Аноны, аопомогите как сжимать порно правильно,какой битрейт и прочее, у меня 6650xt если что, пробовал в handbrake
Нахуя?
Как сжимаете аудио в opus? Обнаружил что нужно ДОВОЛЬНО СИЛЬНО понижать громкость перед экспортом чтобы избавиться от клиппинга. В итоге получается что opus в 2 раза тише чем mp3 (пикрил opus и flac)
Вижу на пикче клипинг что сверху, что снизу. Осциллограмма, срезанная по линеечке, это и есть клипинг. Нормальная осциллограмма так не выглядит. Т.е. клипинг у тебя в исходнике, а не в опусе.
Под словом клиппинг он, наверное, имеет в виду повышение уровня и вылет за 0 dB после конвертирования в opus.
Не делай тише - не будет тише. Это тебе не wav, чтобы уровни одни и те же оставались.
>Под словом клиппинг он, наверное, имеет в виду повышение уровня и вылет за 0 dB после конвертирования в opus.
Ок. Скорее всего, это явление Гиббса на срезанных верхушках исходника. При удалении психоакустической моделью высоких частот на этих срезах возникает переходный процесс, который и улетает за 0 dB. Если при воспроизведении его не слышно, лучше всего просто забить. Исходник уже всё равно проёбан.
Чтоб было места дохуя
по теореме котельникова файл с частотой дискретизации 44.1 кГц физически не может содержать полезный сигнал выше 22.05 кГц (ровно половина частоты дискретизации)
Та там всё по этим пыльным талмудам и рассчитано было при разработке аудио сиди. 44.1 это теоретический идеал с нахлёстом в замкнутой системе, но при этом практический минимум.
С другой стороны, воспроизводящая консьюмерская техника в последние годы или стагнирует или деградирует, потому один хуй не с чего послушать разницу между 48к и 44.1к — цапы говно, наушники говно, колонки говно. За глаза и за уши порезанных спектров лосси форматов по итогу.
-svtav1-params film-grain-denoise=0/-svtav1-params film-grain=50?
https://trac.ffmpeg.org/wiki/Encode/AV1#Filmgrainsynthesis
Ты хочешь удвоить частоту кадров? Последнее, что помню, у FFmpeg был хреновый интерполятор, слишком много артефактов, а вот в AviSynth с SVPflow вполне норм, у меня даже хранятся несколько видосов с удвоенной частотой. Очевидно, что 25 желательно конвертировать в 50FPS, 29.97 в 60FPS, ну а 23.976 в 50FPS, т.к. наиболее близкое значение и не надо будет лишние кадры интерполировать. Телики и плееры обычно поддерживают 23.967/24/29.97/50/59.94/60.
ну wavpack в режиме hybrid есть в принципе. при макс сжатии и битрейте в 400 звук прозрачный и меньше флака в 2-2.5 раза. а если создать ещё и файл коррекции то вот тебе тот же lossless. и хорошо когда есть большой запас по битрейту. в vorbis 500, aac 320, mp3 320, у opus 510 к тому же резкая обрезка на 20кгц и ресэмплинг в 48кгц (что как бы даёт понять что это именно lossy по духу и есть риск ошибок и они могут что то вырезать чтобы втиснуться в эти рамки и задыхаться в них, психоакустика и тд) а у wavpack лимит аж 2048 или около того и он изначально lossles, ничего не вырезает, лоупасса нет и не ресэмплит. а больше то ничего как будто и нет, если рассматривать хотя бы то что как никак обновляется и улучшается до сих пор.
больше реально ничего нет. либо старая экзотика без поддержки как musepack, либо проприетарный мусор либо те что режут звук по определению.
Я долго надеялся, что кто-нибудь вытрясет сорцы musepack и продолжит его поддерживать, человечество не знает что потеряло.
А твои заёбы с вавпаком не понимаю. Формат недооценённый, конечно, но нахуй он тебе, как и запасы по битрейту. Всю музыку мира решил сохранить в максимальном качестве при минимальном размере? У меня флацковая библиотека ни разу не переваливала за терабайт, хотя немаленькая. Всю её на портатив скидывать тоже непонятно зачем, а если надо, то опус/qаац гуд инах в районе 144-192 битрейта.
ну, если хочется можно использовать mpc и сейчас.
как пишется на оф сайте (текст недавний на 24 год):
Немногие в мире обладают передовыми техническими возможностями, необходимыми для настройки психоакустической модели, используемой Musepack, без негативного влияния на и без того исключительное качество звука. Нет намерения чинить то, что не сломано. Но как всегда, приветствуются любые дополнения к исходному коду.
я для любопытства сконвертил в фубаре 1 флак весом 126мб в 6 разных форматов. вот что получилось по весу:
1) mp3 41.9 мб (--noreplaygain -k -q 0 -b 320) вес самый низкий потому что cbr
2) opus 42.2 мб (--bitrate 320 --vbr --music ) плюс ресэмплер ardftsrc в 48кгц качество insane
3) musepack 42.5 мб (--xlevel --quality 10)
4) apple aac 44.6 мб (--quality 2 --lowpass 22000 --no-optimize -V 127 -i)
5) wavepack 55.5 мб (-i -q -hh -x6 -b400 -m) без корректировочного файла
6) vorbis 59.4 мб (-q10)
Если ты занимаешься говноинтерполяцией (а тем более кадров, снятых с киношной выдержкой, вместо цифровой генерации мгновенных рендеров), то тебе уже насрать на результат, и нет смысла задумываться о частоте кадров.
Ты задаёшься вопросом о надписях на рукоятках на пульте управления ядерного реактора, а что происходит с ним самим, как бы и не важно.
Вы о сферической хрени в вакууме спорите. Если в студийной технике, работающей часами и днями, есть точные генераторы частоты (или даже вход внешнего источника, по которому синхронизируется всё оборудование), то в остальном мире полно материалов из цифровых источников, где может использоваться и ровно 60/50/30/25/24, и «типа 60/30/24 со скидкой на NTSC, но не точно как в NTSC, а просто похожая циферка, которая в нашем бытовом устройстве или кодировщике позволяла работать». Что есть, с тем и надо работать, понимая, каковы последствия, и как их избежать.
Более того, возникновение цифровых форматов со строго 24 кадрами в секунду в некоторых случаях приветствовалось как способ избежать конвертации и разъезжания туда-обратно при монтаже на телевизионной технике.
Смех в том, что когда классические фильмы выходили, и их крутили в кинотеатрах с плёнки, результат никогда не был таким точным. Смену бобин и неточности фокусировки проектора почему-то не воспроизводят на блюреях.
У тебя какая-то проблема с импортом фалов, выводом графиков или их пониманием. Кодеки для аудио с громкостью ничего не делают (если совсем уж не завалить сигнал артефактами сжатия на низком битрейте). В Opus используется конверсия в 48 КГц, то есть несовместимым становится формат, а не уровень громкости.
Шиза безграмотная. Бессмысленно дрочить лучше на письки, чем на байтики и циферки, а то вот так деградируешь до того, что не понимаешь разницу между сжатием с потерями и без.
>У тебя какая-то проблема с импортом фалов
Если не уменьшать громкость при экспорте в opus - появляется много клиппинга. На солсике поэтому раздают опусы с уменьшенной раза в 2 громкостью. При экспорте в mp3 такой проблемы нет
И опус и мп3 конвертирую во флак сразу же после скачивания, чтобы сохранить лосслесс звук, так как в лосси биты деградируют со временем из за гамма лучей из космоса или как эта хуйня называется не помню точно
В нём ещё и динамический рэндж растёт, если по-тише делать перед сжатием. Только выигрываешь, короче.
Ты хочешь сказать, что самый популярный кодек делали идиоты, которые этого не заметили?
Или, может, долбоёбы, которые используют формат с плавающей точкой для заранее известного аудио, не понимают, что в нём не существует верхнего уровня громкости (точнее, он огромной и на практике не имеющей смысла величины), и что абстрактная нулевая точка задаётся произвольно, и что надо программы приводить в соответствие какому-то стандарту, если уж на то пошло?
Анончик, выкладывай свои флак на торренты, надо помочь людям
В прошлый раз мы как всегда срались про кодеки, особенно про качество 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