>ждем ввода WebP и AV1, пишем Нариману Абу в /d/
Долго будете ждать.
Третьего дня по совету проверенного поискового гиганта эксперементирую с новым мегаформатом webp, задыхаясь от жадности к хранилищу, перекодировал пак трапов. Размер и качество, мое почтение, хорошо сделали. Кроме того, удаление шумов и артефактов приятно щекочет простату. Был решительно готов закодировать все фото, однако, малолетнему кодеру невдомек, что метаданные удалять не стои. Как побороть проблему?
когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было, хотя вебмы действительно более значимы.
>WebP
Так работает же, не?
А не, пизжу, не работает.
> WebP
Очередной зонд пиздящий данные пользователей через метадату. Хотя что еще ожидать от компании специализирующейся на ботнетах.
>пиздящий данные пользователей через метадату
Каким образом это происходит?
У меня как раз обратная проблема: он не сохраняет метадату из жпега
учитывая что для vp9 нет хардварного энкодинга на gpu, HEVC сжимается хардварно на огромном количестве видимокарт, а сжатие vp9 занимает овердохуя времени имею сказать следующее - ебитес врот своим vp9
av1 ваще нахуй нинужон, по тем же причинам
>HEVC
Не проигрывается в лисе.
ну вот поэтому или скачивай hevc и проигрывай локально, или кушойти x264\vp8
из-за чего получается такой блок серый снизу? я просто перекодировал
>m4v
Что это? Зачем?
Новые люди, новое время, когда то по моим алгоритмом работало сжатие, один раз мы пытались сжать ядро планет, что бы получать неограниченное тепло, но математические алгоритмы не сработали!
Какие параметры использовать, если нужно просто к вебмке сабы добавить?
-vf subtitles=
походу
Вся суть вебп одной картинкой. Меньше артефактов - меньше деталей.
Алсо вебп, в отличие от того же heif не умеет в градиенты.
>меньше деталей.
Нет.
> Алсо вебп, в отличие от того же heif
Не опенсорс, уноси.
>не умеет в градиенты.
Эм что?
>Нет.
Сравни облака, особенно слева.
Чем avif под пердолексом пожать?
Как этот хентай можно сравнивать с божественным вебпом?? Все детали жпега - это артефактная лестница
png лучше всех, чтоб и требовалось доказать
Этот хентай поддерживается в любом браузере, в любой перделке. Вебп - гуглоговно без задач.
Говно мамонта
Абу выпилил av1? Раньше нормально заливались шешебы.
Или вы про av1 для картинок?
А нахуй надо? Глобальное потепление приближать, но зато Абу за хостинг меньше платить?
Превью нет
Эх тилибон через vlc не осилил
Последняя версия?
Даже авиф мылит.
А как еще реализовать сжатие?
Имитировать детали артефактами, например? 30 лет так живём уже.
Можно было бы анализировать картинку и по маске псевдослучайный шум перлина натягивать, чтобы этой кожи младенца не было.
Короче свёл исвудыча, чтобы размеры были одинаковые.
8576 clee.jpg (jpegoptim --size=8k)
8522 clee-26.webp (cwebp -q 26)
8251 clee-28.heif (heif-enc -q 28)
Но мыло лучше артефактов, особенно в движении. А шум это уже какая-то отсебятина.
Мыло нужно видемокодекам, чтобы вектора движения долго можно было использовать и не накапливать ошибку.
В статических кодеках рулят другие принципы.
Последний эксперимент: даунскел до 0.5, webp оптимизация до 8282 байт (-q 78) и последующий апскел через ESRGAN.
Хевк неплохо тут отработал. А размер точно одинаковый?
Можно оригинал?
Эхх, а сейчас там заборов понаставили, нипалазать.
Говорят, что ав1 будет лучше хевка. Что-то мне сдается, что это пиздеж. Даже хевк против х264 хуже в плане детализации. Сужу по примерам аниме, неоднократно делал сравнения.
Случайная фотка из инета была. Не гарантирую, что он предварительно не был пожат.
> А размер точно одинаковый?
Размеры подписал. HEIF даже чуть меньше:
webp - 8522 байт
heif - 8251 байт
Короче енкодер avif я нашёл тут: https://github.com/Kagami/go-avif/releases
Где бы теперь декодер найти, чтобы без конпеляции и пердолинга?
Забил короче на avif, оставил jpg, webp и heif. Скрипт берёт картинку и жмёт тремя разными кодеками до одинакового размера.
Тут глаз в 4, 6, 8 и 10 кб.
Тут глаз в 4, 6, 8 и 10 кб.
Пятикилобайтный клинт.
Норм
трёхкилобайтный шакал (jpegoptim тут схитрил и пожал до 3,9, но webp один хрен посасывает)
Для ценителей.
Здесь heif закодировал больше всего деталей, хотя заметны мазки внутрикадрового предсказания
heif > webp > jpeg
Здесь heif сосёт.
Лицо как у куклы, выглядит пластмассово. Гиганские блоки с явными арктефактами звона. Внутрикадровый предиткор превратил брови в прямые линии.
webp > heif > jpeg
Когда писал тот пост не обратил внимания на размер. А там же jpeg и webp по 2 мегабайта весят, а heif 1 мбайт. Так сравнивать нечестно. Переделывай.
*килобайта и кбайт соосветсвенно
Забыли ссылку на гайд по webm кодированию в шапку треда добавить
https://github.com/pituz/webm-thread/wiki/webm-encoding
>Переделывай.
Эта картинка была вручную была собрана из максимально сжатых вариантов, не сравнивай по ней, сравнивай по 3к варианту.
> webp > jpeg
Насчёт этого бы поспорил. Чисто внешне по количеству деталей webp тот же жипег, но у жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит.
>жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит
то есть тебя не смущает убитая цветопередача вследствии задранного квантователя и примитивного алгоритма компрессии.
Как по мне вместо хранения ВЧ квантованных до металлического звона лучше срезать их НЧ фильтром и сохранить изображение в меньшем разрешении.
WEBP хотя бы пытается замаскировать блочность, как и h264 и всё что после него.
Главная проблема webp в том, что там даже не vp9, а устаревший vp8. Ещё одна проблема этого формата в том, что хоть там и взяли за основу видеокодек vp8, но анимации он сжимает только intra фреймами. Из-за этого гифки сжимаются в лучшем случае на 50%. Поэтому я в 2019м кодирую гифки в неудобный для infinite-loop анимаций формат webm.
Еще сейчас набирает популярность формат apng. Это lossless формат, который сжимает гифки на 5%. Да, у него есть преимущество перед gif, так как он может закодировать true color анимации без потерь, да еще и с настоящим альфа каналом. Но большинство гифок это нарезки из фильмов, зашумленные дизерингом из-за ограничения в 256 цветов на одном фрейме, и там это lossless кодирование не нужно в принципе.
>apng
Для этой хуйни уже появились оптимизаторы, затирающие повторяющиеся части у последующих кадров?
>4 пик
Если не рассматривать картинку увеличенной в близи, то, ЖПЕГ безоговорочно лучше, больше деталей и информации сохранено.
Во сколько раз нужно уменьшить картинку, что-бы jpeg стал лучше?
На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
>На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
Я вижу низкочастотные (те которые в левом верхнем углу на пикрелейтед) базисы дискретно косинусного преобразования, а не детали. Их убил задранный донельзя квантователь. А от даунскейла низкие частоты смещаются к более высоким, а высокие пропадают, так как их срезают для предотвращения алиасинга. В данном случае мы не видим потерю высоких при даунскейле, поскольку их и небыло в данном пережатке.
Tы слегка перепутал, jpg это то, что слева.
Как сделать свой кодек, который нагнет webp и прочие jpg?
Никак, изучай плюсы, матан, питон, алгоритмы, нейронки, машоб
>Tы слегка перепутал, jpg это то, что слева.
Ну вот и говорит о том что с лева.
С лева видно больше деталей.
Ты математику свою вшивую в оценку сжатия не неси. А то уже целое поколение долбоёбов выросло, которые музыкальные кодеки по спектрограмме оценивают.
Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
Свидетели деталей, что с вами не так?
Если закодировать mp3 в 32 кбит/c, задрав срез lowpass фильтра на 20кГц, используя кодировщик, псиоакустическая модель которого позволяет сделать такое, ты получишь больше частот, ценой увеличения металлического звона и общего снижения качества, так как на те-же частоты выделяется меньше битрейта.
В случае с ОП - пиком, там размер файла настолько мал, что на деталей бит не осталось, всё в квадратики ушло.
>А давайте мы снизим разрешение и посмотрим на квадратики еще и интерполяции. В jpeg квадратики больше, значит и деталей больше.
Так вы только снижаете разницу между кодеками
>Ты математику свою вшивую в оценку сжатия не неси.
Я может быть бы и молчал, если бы jpeg картинка не рассыпалась на эти самые базисы ДКП, и свидетели деталей тоже бы молчали.
>Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Я вижу, то что у webp отображается как линии и контуры, то у jpeg превратилось в кашу из блоков. А ведь линии и контуры это тоже детали.
Репорт.
>>2698490
Одобряю, работает
Одобряю, работает
Привет подстилка нариманова
Нет ноздри в твоём webp, пропала. Шакал без ноздри не шакал.
>Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.
Ну давай хоть MSE посчитай чтоле, идиота кусок.
jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА, неважно что кому нравиться, он использует объективную метрику, может неидеальную, но основанную на объективных свойствах человеческого восприятия.
>Я вижу, то что у webp отображается как линии и контуры
Белое пятно лучше квадратных глаз и носа?
Без глаз и носа непонятно что это, человеческое лицо, или тупой фиолетовый двачер.
Хорошая собачка, держи кость.
WebP - замылил дорогу, замылил лес.
Потерял цвета на дороге.
Сделал логотип на строении слева ЧЕРНО-БЕЛЫМ.
Что за сука сжимала webp?
Ты можешь сколько угодно усираться что
>jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА
но он всё равно не может закодировать линии в 3,6кБ.
Здесь я специально обвел области на которых у webp линии более менее четкие в то время как у jpeg там каша из блоков
>Канал связи с космосом
еще ни разу не открывался
>Закрывает третий глаз
как будто он существует
>блокирует чакры
и так заблокированы
>Убивает бога
убить можно только то что есть
>выводит пришельцев
то-то я в современной порнухе эти тентакли видел, это же инопланетные глисты
Какой-нибудь просмотрщик уже может в avif?
Только браузеры через avif.js.
А кодировщик есть (XnviewMP)?
спосебо, но это говно какое-то.
Хуй знает как этот ваш heif жать, нашел какой-то онлайн конвертер, но он цвета проебал
Перед тем, как выкладывать результаты в пнг, удаляй метаданные о цвете в tweakpng. Или же следи, чтобы они были одинаковые у всех пикч.
avif>webp
Да, там деталей побольше, словно render distance выкрутили. Но облака мыльнее, да.
avif vs heif
Как это вообще сравнивать?
Возникает ощущение, что кодировщик heic вместо тебя редактирует уровни. Вы уж там разберитесь с full->tv->full range преобразованиями.
По детализации разница не большая, но heif кажется детальнее (это при том что avif сложнее кодировать). Может avif потом допилят по качеству. Пока они ускоряют декодеры.
Вы сжимать webp не умеете
cwebp -size 46900 -z 9 -m 6 -f 100 '15764428295940.png' -o '15764428295940.webp'
Размер: 43,6КБ
Помогите объяснить необъяснимую хуйню. Я запостил в клиент вотсапа видео ролик, и если его проиграть - видно последний кадр. НО, если проиграть его в VLC или даже открыть в VirtualDub - этого кадра там нет! Это как блять?
Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
бамп
>libx264 slow 320k (6s)
>libx265 slow 320k (55s)
>libvpx-vp9 320k (3m)
>libaom-av1 320k (6h 15m)
Зачем так кодировать? Как можно сравнивать x264 закодированный за 6 секунд с av1, который кодировался 6 часов?
Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
>Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
На таком битрейте будет одинаково хуевым.
Sup, подскажите как достать аудио дорожку из видео. А после склеить с видеорядом лучшего качества.
Достаем звук:
ffmpeg -i видос.webm -vn -c:a copy звук.opus
Удаляем звук:
ffmpeg -i хороший_видос.webm -c:v copy -an хороший_видос_без_звука.webm
Склеиваем:
ffmpeg -i хороший_видос_без_звука.webm -i звук.opus -c:v copy -c:a copy готово.webm
а какого-то гуи для этого вашего ффмпега не изобрели еще? чтоб не печатать 100 символов а сделать 5 кликов?
Есть много гуев, но не очень то и нужно.
webp lossless как замена .png? Годнота! Практически во всех случаях webp получается меньше, а в среднем процентов на 20%
.
webp lossy как замена .jpg? Хуета! Нет, не так, webp lossy - в принципе хуита. Даже на 100% проёбывает непозволительное количество информации и совершенно отвратительно работает с градиентами.
Так что в своей картинкпомойке перевел png в webp, а jpg различной степени сжатости пришлось оставить jpeg'ами разве что pingo'й прогнал.
Соглы.
Разве что heif сейчас вполне доступен стараниями эпола. Для лосси он уже однозначно обходит жопег.
>webp lossless
Через чего кодируешь и с какими параметрами?
xnconverter, сжатие на шестерочку.
Мокрописьки не нужны. Почти все графические видеоредакторы/конверторы и есть гуи к ффмпег.
Зачем нужен корпорастический webp, когда есть flif?
Затем что вебп открывается?
> FLIF.png
В интернете встречаются картинки порой огромных размеров, таких как 7000х7000, которые очень долго декодируются на Core2duo.
Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.
И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.
И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
Современные кодеки ставят целью максимальное сжатие, а тобою описанное — залупа в колёсах. Тем более, сейчас в любом шаёми 8 вёдер и 4+ гб озу.
>сейчас в любом шаёми
>Xiaomi Redmi Go 1/16Gb
>4 ядра
Всеравно говно.
Двачую.
просматривал свой пак картинок. Оказалось что aritmetic jpeg тормозит сильнее чем webp. Причём aritmetic jpeg тормозит на картинках если размер больше чем 1000х1000, а webp если больше чем 2500х2500. И еще мне показалось что lossless webp меньше лагает чем lossy webp
Ну и нахуй ты это говно советуешь? Рассинхрон будет, ебаный ты полудурок, блядь.
Ага, стекломойной пидорахе лучше знать.
Да походу av1 будет как и vp9 только в ютубе пользоваться таким темпами.
А hevc уже захватывает сердца.
А hevc уже захватывает сердца.
Так имплементаций пока нет, и ускорение тонет. Если начнёт жать хотя бы 0,5 fps, тогда и появятся рипы.
Хевку тоже не один год понадобился.
Так а чё ты хочешь?
>libx265 slow 320k (55s)
>libvpx-vp9 320k (3m)
Ты думаешь кто-то будет ждать кодека, который загружает 4 потока по дефолту, в то время как x265 загружает их все, как это было еще с x264. Да и знающему x264 проще освоить x265 чем libvpx-vp9.
ты забыл про двач с его webm-ками
Как можно было такую хуйню в продакшен пускать? Ёбаный стыд.
Я, к слову, о кодеке, потому что только их VP и ублюдочный WebP Lossy так хуёво работает с градиентами.
Ты как блядь рубашку снял? Уноси своего скриптонита и таблетки прими.
Битрейта небось не хватило, открой mp4 версию и там посмотри
Ну а чего вы хотели от 8-битного lossy кодека?
Начнем с того что 8 бит на канал недостаточно для отображения всех различимых оттенков даже человеческим глазом. Для сглаживания градиентов применяют костыль, который называется дизеринг. Дизеринг это подмешивание шума с минимально возможной для данной разрядности амплитудой, который создает субъективное ощущение большей разрядности.
Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
Двач, что с тобой не так?
Как можно было так распидорасить thumbnail?
Чёрно-белые пнг с альфой коряво обрабатываются.
>Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
В этом и пиздец. Кто в 2020 устраняет избыточность путём выпиливания ВЧ?
>jpeg живее всех живых
>практически все видеокодеки все еще занимаются DCT преобразованием, устраняют избыточность путём выпиливания ВЧ и блочат при нехватке битрейта
>адекватной замены гифкам нет до сих пор
>что-то спрашивать про 2020-й год
> деды фильтровали и ты фильтруй
так и победим
так то фотокамеры шумят достаточно сильно что-бы при сохранении в jpeg не заморачиватся с дизерингом.
А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
Шрек в 8 метров.
>128x72
убей себя.
> Video: av1 (Main), yuv420p(tv), 128x72, SAR 1:1 DAR 16:9, 4 fps, 4 tbr, 1k tbn, 1k tbc (default)
> Stream #0:1: Audio: opus, 48000 Hz, mono, fltp (default)
Чем на шиндофонах смотреть av1?
для воспроизведения этого говнокодека нужен суперкопьютер.
Мой шиндофон тот ещё суперкомпьютер. Но VLC увпшный, со старой либой, нет там av1.
Опус не может в 44100.
For those curious I used the latest libaom git with a video bitrate of: 4.6kbps, 2 pass, cpu used 1, resized to 72p and 4fps. My audio bitrate was: 7.5kbps because anything less was headache inducing.
>для воспроизведения этого говнокодека нужен суперкопьютер.
>CPU: Intel Core2 4300 @ 2x 1.8GHz
>libdav1d 0.5.2
>ffmpeg -c:v libdav1d -tilethreads 2 -i 'COSTA RICA IN 4K 60fps HDR (ULTRA HD)-LXb3EKWsInQ.mkv' -benchmark -f null -
144p
>frame= 3681 fps=288 q=-0.0 Lsize=N/A time=00:02:02.82 bitrate=N/A speed= 9.6x
240p
>frame= 9404 fps=111 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=3.72x
360p
>frame= 9404 fps= 65 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=2.17x
480p
>frame= 9404 fps= 39 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=1.31x
ffplay отказался воспроизводить av1 через libdav1d, поэтому применял костыли вида
>ffmpeg -c:v libdav1d -tilethreads 2 -i 'input.mkv' -vcodec yuv4 -acodec copy -f matroska - | ffplay -
До 360p воспроизводится нормально. На 480 есть тормоза (наверно из-за ремуксинга)
>frame= 2823 fps= 28 q=-0.0 Lsize= 1695013kB time=00:01:34.14 bitrate=147497.3kbits/s speed=0.929x
Лол 480р уже тормозит, а что там с 1080р или 4к? Даже на i7 будет тормозить. Пусть гугл себе в одно место засунет этот тормозной говнокодек.
Видишь разницу между форматом видеокодека AV1 и декодером этого формата? libdav1d
Реализация гугла libaom-av1 декодит ещё хуже.
На i7 ничего не тормозит уже больше года, даже 4к.
> - libdav1d 0.1.0 73067e5
> libdav1d -threads 4 -tilethreads 4 - 58 fps 2.31x speed
https://forum.doom9.org/showthread.php?s=c9296846762f3daa7940cfa73d337f3d&p=1859793#post1859793
> гугл
>ничего не тормозит
>-threads 4
Достаточного одного ядра для воспроизведения vp9 4к, а для av1 нужно 4? Хочешь сказать, что это не говнокодек?
Довольно логично, что для воспроизведения кодека из 2018 не годится камень десятилетней давности.
хитрые_лица_производителей_железа.png
Ага, новый, требовательный к железу кодек для них как бальзам на душу. Уже предчувствую батхерт васянов с коре дуо, когда его начнут вводить повсеместно. Чому видево про танки логает??
>начнут вводить повсеместно
Пираты пользуется тем, что удобно для народа, а на остальное насрать.
Ютуб отдаёт то, что ему выгодно.
А ему выгодно экономить на хранилище.
>на остальное насрать
Действительно, с чего это неуловимого джо должны волновать проблемы 90% оставшегося население
>Ютубу так выгодно экономить на хранилище что кроме h264 + aac версий он еще кодирует и хранит vp9 версии и параллельно еще кодирует av1 для тестов.
Да, совершенно насрать на анальные сервисы.
Кстати, у некоторых старых видосов нет vp9 варианта.
Основное гемор - в поддержке CDN сети, а там только самые ходовые форматы хранят.
[libdav1d @ 0000016076c4a840] libdav1d 82eda83
Stream mapping:
Stream #0:0 -> #0:0 (av1 (libdav1d) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf58.35.101
Stream #0:0(eng): Video: wrapped_avframe, yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc (default)
Metadata:
encoder : Lavc58.65.102 wrapped_avframe
frame= 3604 fps= 49 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=1.97x
video:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=255.938s stime=8.812s rtime=73.274s
bench: maxrss=418548kB
Хуй знает вообще, в чём проблемы. 4к и ноутбучная затычка вместо проца.
> кодируем минутный ШебМ джва часа
Вся суть h265?
>Вся суть h265?
Вообще-то, h265 обычно пихают в матроску.
И типо что? Быстрее кодирует?
Типо разные контейнеры, mkv и webm.
Хуевк захвати сердца уже лет 5 назад, если не больше
*Захватил
Кстати да, VP9 на ютубе ублюдошно с темной частью градиентов работает, артефачит ее на каадраты. Я правда не могу быть уверен, что контентмейкер загрузил не уже в таком качестве
8 бит на канал кстати с дитхерингом просто прекрасно выглядит, даже повышение до 10 бит на канал ничего не дает визуально. Тут видать YUV 8 бит, а не RGB 8 бит потому что
Да никто так-то не выпилит fallback на H.264, ибо афони
Ремухи UHD BD будут в том, в чем сами UHD BD, а это HEVC
2716118
Не знаю, какую разницу ты увидел между yuv444p и rgb.
Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.
>даже повышение до 10 бит на канал ничего не дает
У тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
Не знаю, какую разницу ты увидел между yuv444p и rgb.
Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.
>даже повышение до 10 бит на канал ничего не дает
У тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
> Не знаю, какую разницу ты увидел между yuv444p и rgb.
Ну я не знаю на счет именно yuv444 - таких видосов раз-два и обчелся.
> У тебя 10 битный монитор и сигнал с видеокарты?
Да, и я с лупой проверял тестовый 10-битный пнг в мадвр. 8 бит с дитхерингом неотличимо от 10 бит с дитхерингом. Без дитхеринга да, легко отличимо.
Культовый фильм теперь в 20мб!
Полтора часа в 20 мб! Я заинтересован. Можете пояснить залётному за все эти виды сжатия?
Современные кодеки и низкий битрейт: av1 - 20кб/с — видео и opus - 11кб/с — аудио. Ну и 16 часов кодирования.
*Кбит/с
Быстрофикс.
На N64 пригодилось бы при портировании Resident Evil 2
Т
На N64 пригодились бы терафлопсы, чтобы av1 декодировать.
Хотя да))
а на русском конвертера для webm нема?
Как же хочеца HEIC, хоспаде.
Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)
Оче круто.
Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.
Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как.
Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.
Из явных косяков - на одном из сложных JPG заметил, что он из ровных линий, делает квадратные (как будто понижение разрешения рендеринга в какой-нибудь игре), но были бы доступны крутилочки-вертелочки, думаю, можно было бы подобрать универсальный профиль.
Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP, а хочется повсеместного внедрения, чтобы и на телефон скинуть и на сайт.
Еще бы AV1 пощупать...
Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)
Оче круто.
Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.
Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как.
Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.
Из явных косяков - на одном из сложных JPG заметил, что он из ровных линий, делает квадратные (как будто понижение разрешения рендеринга в какой-нибудь игре), но были бы доступны крутилочки-вертелочки, думаю, можно было бы подобрать универсальный профиль.
Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP, а хочется повсеместного внедрения, чтобы и на телефон скинуть и на сайт.
Еще бы AV1 пощупать...
Сап, сжимач, возникла такая ситуация. Имеется жёсткий диск, который заполнен лоли хентаем уже чуть менее чем полностью файлами всевозможных типов и форматов. Реквестирую как лучше всего имеющееся файлы перекодировать и сжать для минимального размера при сохранении качества или его минимальных потерях.
И что почитать чтобы разобраться в этой теме?
И что почитать чтобы разобраться в этой теме?
> при сохранении качества или его минимальных потерях.
This
https://css-ig.net/pingo
Настройки варьируются - lossless/небольшие потери/квадраты.
Но это ведь только для фото. А у меня кроме их там и видео, и аудио, и текст, и даже несколько программ в портативных изданиях.
Алсо я не против перековырять всё вручную. Софт из оп поста пойдёт под любые медиаформаты? Как кодировать?
> Софт из оп поста пойдёт под любые медиаформаты?
Да.
Видео кодируй с такими параметрами: -c:v libvpx-vp9 -b:v 0 -crf 32 -c:a libopus формат webm
Или такими: -c:v libx265 -crf 28 -c:a aac формат mp4
Аудио: -vn -c:a libopus -b:a 128k
> текст, и даже несколько программ в портативных изданиях.
7-zip
> чтобы и на телефон скинуть
У меня обратная задача - как смотреть с телефона в старой версии АЦДЦее (которая еще не полным калом была) никак
Медиа не сжимай, только текст, бинарники и подобное. Медиа и так в сжатом виде хранится, перекодируя не имея исходников ты просто получишь шакалов или ещё больший файл, в случае lossless. Всякие универсальные lossless алгоритмы, вроде lzma2, или даже жестокие алгоритмы семейства paq, поверх уже сжатых кодеками файлов дадут тебе парочку процентов.
Ну, фиг знает.
По порядку:
png (6,43 МБ) -> heif (2,10 МБ) -> jpg (1,20 МБ).
Heif сохранял гимпом без потери качества.
Jpg c максимальным -quality 0 в ImageMagick.
По качество/размер jpg, очевидно, сосет.
heif (313 КБ) -> jpg (318 КБ).
Оба с 50% качеством сконвертированы.
Webp (320 КБ) тоже.
Про размер согласен. Кажется тот онлайн конвертер что-то мудрит. Позже пробовал переводить JPG в WebP и он каким-то образом выдавал результаты, которые были всегда меньше оригинала и при этом обработаны явно с помощью WebP Lossless, потому что характерных артефактов на градиентах не было.
При этом, когда я пробовал сжать эти же изображения с помощью нативной библиотеки cwebp результаты в WebP lossless всегда были в полтора-два раза больше, а схожий вес получался только с помощью WebP lossy, где всплывали видимые сразу же видимые артефакты.
Другими словами, как конвертер тот сайт очень хорош, но не объективен.
Еще, заметил, я думал, что это у меня из-за разницы вывода в гимпе и обычном картинкоменеджере - HEIC зеленит изображение, что довольно неприятно.
>HEIC зеленит изображение, что довольно неприятно.
Кстати, да. Гимп зеленит на выводе.
ImageMagick и gimp в png.
Спасибо.
> перекодируя не имея исходников
Какие исходники?
> Аудио: -vn -c:a libopus -b:a 128k
Формат opus, забыл
>джипег как образчик сжатия на 10 из 10 по шкале ебучих шакалов
>ко-ко-ко-ко-пок-пок-порЭЭЭЭЭк унижаем пээнгэблидей!!!
А?
Какой положняк по кодекам и софту?
av1 > h265 > vp9 > h264
opus > vorbis > aac > mp3
heif > webp > jp2 > jpg
ffmpeg для видео и аудио.
convert из ImageMagick для изображений, но heif только чтение.
av1 > h265 > vp9 > h264
opus > vorbis > aac > mp3
heif > webp > jp2 > jpg
ffmpeg для видео и аудио.
convert из ImageMagick для изображений, но heif только чтение.
>Какие исходники?
RAW, нетронутые кодеком данные с камеры или микрофона.
Порча информации.
Это ты создаёшь flac треды в /б?
А, ну, если это чисто проблема GIMP'a, тогда формат хороший - одобряю.
Тогда положняк -
WebP Lossless - замена PNG.
HEIC/HEIF - замена JPG.
Ждём AV1
> когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было
На форчане до сих пор нет VP9 лол.
aac строго лучше vorbis, vorbis имхо даже хуже mp3, но я накину ему за открытось
jp2 - маргинальщина, которой никогда не было
jpg и webp - примерно одного уровня, вопрос уровня "мыло или кубики", кому какие артефакты больше нравятся
avif очень потанцевальный формат, но в него вообще никто не умеет
>convert из ImageMagick
Говнокомбайн. Только специализированные енкодеры и оптимизаторы.
>Порча информации.
Устранение избыточности.
>Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP
Nomacs через костыли поддерживает, макос/шин10 умеет, последние мобилки в хейф по умолчания снимают.
Осталось только браузеры научить.
Избыточными будут только часы перекодировки.
>Говнокомбайн
Удобно через консольку работать с нужными кодеками изображений. FFmpeg у тебя тоже говнокомбайн получается.
>шин10 умеет
Там пздц, конечно.
В мсторе hevc/heic платный, а бесплатная версия только если железо поддерживает (мне повезло с этим). Открывается все это либо через стандартное "Фотографии" (или др софт из мстора), который мылит картинку. Либо через тормозные костыли в каком-нибудь xnviewmp открывать.
Самая большая проблема в низкой распространенности новых форматов в приложениях и закрытом коде.
> vorbis имхо даже хуже mp3
Неа
Можете нормально пояснить несведующему анону про все эти ваши форматы и кодировки? Я сейчас вижу эту картину примерно так:
Фото
JPEG - качество средней паршивости, при сжатии шакалится
PNG - лучше чем предыдущий, но и места отжирает больше
WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
HEIF - НЁХ, скорее всего замена пнг
Видео
Тут нихуя непонятно, но webm>>mp4
Кодеки
В этом тёмном лесу нихуя не ясно.
Аудио
MP3 - для лохов
OPUS - выбор мастеров
Фото
JPEG - качество средней паршивости, при сжатии шакалится
PNG - лучше чем предыдущий, но и места отжирает больше
WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
HEIF - НЁХ, скорее всего замена пнг
Видео
Тут нихуя непонятно, но webm>>mp4
Кодеки
В этом тёмном лесу нихуя не ясно.
Аудио
MP3 - для лохов
OPUS - выбор мастеров
> Фото
> JPEG - качество средней паршивости, при сжатии шакалится
Самое худшее качество
> PNG - лучше чем предыдущий, но и места отжирает больше
Идеальное качество, места естессно зрет стоко, скоко надо
> WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается
> HEIF - НЁХ, скорее всего замена пнг
Замена джейпегу, но бровзерами не поддерживается, так что на самом деле не замена
> Видео
> Тут нихуя непонятно, но webm>>mp4
Это контейнеры, а не алгоритмы сжатия
> Кодеки
> В этом тёмном лесу нихуя не ясно.
> Аудио
> MP3 - для лохов
> OPUS - выбор мастеров
Всё так
А видео примерно так, от плохого к хорошему:
MJPEG (в PS1 юзалось)
MPEG2
DivX
H.264/VC1
HEVC/VP9
AV1
Стоит отметить, что у WebP есть два типа сжатия - lossy и lossless (с потерями и без потерь соответственно).
WebP lossless подходит как охуенная замена png, поскольку абсолютно ничего не теряет, а размер ~на 20% меньше.
WebP lossy - ну такоооое. Вроде как замена jpg, но нужно пердолить конвертер ключами, чтобы получить нормальное изображение. HEIC в этом плане будет лучше, но он проприетарный, а значит дальше айфончиков особо не пойдет. Ждём внедрения AVIF.
К слову, почитал документацию cwebp и поэкспериментировал с ключами и вывел универсальную команду для перевода картинокомойки_jpg в картинкопомойку_webp (для png лучше всё же использовать lossless)
cwebp вход.jpg -sharp_yuv -jpeg_like -af -mt -sns 100 -o выход.webp
>-sharp_yuv
Самое важное и нужное. Замечал, что часто после перевода некоторые цвета теряют свою силу и сочность, что для меня лично не приемлемо в принципе. Это команда оставляет видимую палитру неизменной.
>-jpeg_like
Оче годный ключ, который автоматически делает довольно качественную/детализированную картинку при этом равную по весу, либо меньше, чем оригинал (зачастую намного меньше). Позволяет избавиться от игры с ключом -q, что давал разные результаты для больших и малых изображений.
>-af
Автоматическая фильтрация - удаляет мелкие шероховатости после перекодировки.
>-mt
Мультипоточность
>-sns 100
Оставляет большую детализацию изображению совершенно не прибавляя в весе.
Сравнивал выход с ключом/без с максимальными/минимальными свойствами (-sns 100/-sns0) и итоговые ключи выдавали самую качественную картинку на мой взгляд.
В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.
Дополнения приветсвуются.
cwebp вход.jpg -sharp_yuv -jpeg_like -af -mt -sns 100 -o выход.webp
>-sharp_yuv
Самое важное и нужное. Замечал, что часто после перевода некоторые цвета теряют свою силу и сочность, что для меня лично не приемлемо в принципе. Это команда оставляет видимую палитру неизменной.
>-jpeg_like
Оче годный ключ, который автоматически делает довольно качественную/детализированную картинку при этом равную по весу, либо меньше, чем оригинал (зачастую намного меньше). Позволяет избавиться от игры с ключом -q, что давал разные результаты для больших и малых изображений.
>-af
Автоматическая фильтрация - удаляет мелкие шероховатости после перекодировки.
>-mt
Мультипоточность
>-sns 100
Оставляет большую детализацию изображению совершенно не прибавляя в весе.
Сравнивал выход с ключом/без с максимальными/минимальными свойствами (-sns 100/-sns0) и итоговые ключи выдавали самую качественную картинку на мой взгляд.
В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.
Дополнения приветсвуются.
> перевода картинокомойки_jpg в картинкопомойку_webp
дважды пережимать с потерями? во сколько раз выигрыш в весе не написал даже.
>webp
>но бровзерами не поддерживается
Что значит не поддерживается?
https://caniuse.com/#feat=webp
Ничего что не поддерживают только ишак и сафари. А про KaiOS Browser кто нибудь вообще слышал?
>про KaiOS Browser
Очередная швободная поделка, как и всё швободное ПО и ОС - говно
Два .bmp шакалам в треде.
Да, это я что-то на радостях написал от того, что удалось избавится от ужасных градиентов, но всё равно достаточно много деталей мылится, с HEIC'ом вообще не конкурент.
Вот окончательная команда, что получить картинку сравнимой или меньше по весу с оригинальной jpg с приемлимым качеством:
cwebp "$1" -sharp_yuv -jpeg_like -af -mt -sns 100 -q 90 -m 6 -o $1.webp
Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC.
По весу примерно:
1.jpeg - 17 кб
1.webp 13.5 кб
2.jpeg - 1 миб
2.webp 317 кб
При этом довольно интересный эффект наблюдатся - на маленьких зашакаленных jpg webp наоборот делает лучше, убирая своим мылом мусорные квадраты png. собсна первые два пика релейтед.
> Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC.
через 10 лет еще что-то запилят, будешь третий раз её сжимать
>мусорные квадраты png
jpg разумеется. Надо идти спать.
jpg разумеется. Надо идти спать.
У пнг, имей ввиду, размер зависит от проги, сохраняющей его. В фотошопке самым маленьким получается
Не-не, я это знаю, я токо про хеик писал, вебп предыдущей строкой при копировании просто осталось
Хех первая в вебп даже лучше стала))
Ага))
Поясните за FLAC и MKV
FLAC - пожатие аудио без потерь (lossless). Избыточен для 99% слушателей и только для отбитых аудиофилов.
MKV - контейнер, куда удобно запихать кучу дорожек аудио/субтитров. Развит в webm.
> Избыточен
>750 Кбит/с
>при жестких дисках 8 ТБ (66280 лет FLAC музыки)
Алсо
> только для отбитых аудиофилов.
>16 бит
>44,1 КГц
>2 канала
Вы знаете, что miro-video-converter (https://github.com/pculture/mirovideoconverter3) очень круто сжимает!? И ещё вопрос, что это за порода собак?
>66280
Чёт не видел тилибонов с 8Тб.
Мне кажется эта собака сгенерирована нейросетью
Когда кажется, нужно снизить дозу, если бы ты знал породу, то и не стал отвечать вопросом на ответ...
>шкурка для ффмпег
>очень круто сжимает
>последний коммит 7 лет назад
Уникальный софт, достоин уровня /s.
А вообще самый крутой формат сжатия музла - трекерный лол. Типа .mod, .it, .xm, .s3m. Вот этот трек например в оригинале меньше 400 килобайт весит. Но есть нюанс...
Что там по ОПУСУ кстати слышно? Никаких обнов с апреля прошлого года. Всё, кодек уже допилили до идеала, ничего фиксить не надо?
В трекерных очень всегда сухое звучание, без сложных ревербаций, мне не нравится, скушно такое слушать
Ну возьми "мокрые" семплы, в чем сложность? А ведь прикольная идея - кодировать исходный файл не сжатием, а реально конструированием и программированием, раскладывая его на семплы и скриптуя. Чтобы не человек в трекере сразу семплы набивал, а прога из стомегабайтной вавки сделала .mod на 300кб, неотличимый по звучанию от оригинала. Но для похожей хуйни наверно такие вычислительные мощности понадобятся, буквально суперкомп с ИИ. И один файл будет кодироваться сутки.
Ну в Линукс это гуи и удобноя менюшка.
Да, норм идея
Сойдёт для вкатывания новичков. Но для профи это НЕНУЖНО.
Не избыточен, если нужно кодировать потом.
>если нужно кодировать потом
Это студийный юскейс. Флак в бытовом прослушивании никому не всрался.
В гну/линуксе почти на всё есть мокрописька на гтк, мокрописька на кьюте и мокрописька на нкурсес.
и мокрописченый биндинг на питоне
И аналог на расте и го.
Посоны, что выбирать в такой ситуации кроме очевидного flac?
1
выбирай aac
Разницы в звучании все равно не заметишь, зато места сэкономишь
Я сейчас выбираю для скачивания mp3. Потому что по дефолту сейчас везде стриминг пашет. А в нестандартных местах у mp3 выше всего шансы быть проигранными.
aac
Долго расшифровывал твой пост, а потом понял что ты просто зумерок со стримингом вместо hdd. Так зачем тебе вообще выбирать аудиокодек из раздач торрента?
Какой формат сферически и в вакууме является лучшим для анимаций?
Самый крутой наверное - AV1
> AV1
Это же ведь видеоформат, а я говорю про растровую 2д анимацию gif, apng...
avif соответсвенно
а вообще вектор, а также векторные анимации это топ
> вектор, а также векторные анимации это топ
Только вот приличных форматов векторной анимации нет со времён почившего флеша.
А, я думал про анимэ
svg же можно анимировать
Можно, только через жопу.
Потому мы ни масяни, ни древесных друзей в свг не видим.
>стримингом вместо hdd
Как что-то плохое. Цивилизация даёт блага - пользуйся. Нет хотим газку поддавать.
> FFmpeg у тебя тоже говнокомбай получается
Что значит получается? Всегда им был и остается.
>только через жопу
Поясни. Я видел люди пилили анимации, выглядело хорошо.
>Что значит получается? Всегда им был и остается.
А вот тут ты обосрался. Он модульный, перед компиляцией можно выбрать нужный функционал и исключить лишнее.
Тому шо оригиналов уже нет, а повторно шакалить из мп4 будет совсем пиздец
Какой формат самый эффективный для хранения документов? На форматирование строго похуй.
.txt или .md?
.txt или .md?
Обычный ASCII файл, на расширение похер.
Текстового формата с сжатием еще не придумали что ли?
docx
Зачем, когда обычный ASCII файл открывается практически на любой системе очень большим количеством программ.
Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.
Там все очень плохо.
>Там все очень плохо.
С хуя ли?
>Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.
Запили раздел на бтрфс со сжатием zstd.
.7z
Можно в ffmpeg как-нибудь предсказать размер, исходя из параметров и соуса, видео до ожидания 100500 часов кодирования?
зависит от формата, но в случае h264/h265 работает такая формула
((bv + ba) * t) / 8192
bv - битрейт видео (bps)
ba - битрейт аудио (bps)
t - продолжительность видео (s)
Спасибо. Но битрейт видео какой вписывать, если он постоянно прыгает?
А для vp9 есть что-нибудь подобное? Приходится с разными -crf в 3-4 потока одновременно запускать кодирование того же видео (все равно vp9 не полностью проц нагружает, как h264).
Алсо, тут пробовал сравнить гпу кодирование с h264_nvenc и обычный h264, но получаются совершенно разные результаты с командами, отличающимися только этими кодеками.
Аноны, как сжимать аудио через libvorbis, чтобы конечный файл был без видеопотока? Сжимаю коммандой:
ffmpeg -i 1.m4a -c:a libvorbis -q:a 0 1.ogg
но почему-то на телефоне открывается, как видео. Как исправить?
Я ебан. Нужно ставить флаг '-vn', чтобы отключить видеопоток.
Не уверен, правильный ли тред, но ладно.
Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
Дополню, что на ноуте ссд, а на компе проект находится на хдд, может ли это как-то влиять?
>H265
>i7 2600
Ну ты пони. Во-первых, да, SSD может влиять. Во-вторых, 2700k, при всём уважении к Sandy Bridge, монтаж h.265 просто не тащит, как бы ни было горько это признавать.
Жалко. Все-таки удивительно, что ноутбучный процессор 4/8 на 15 ватт справляется лучше, чем десктопный 4/8 большей частоты на 90 ватт.
Ничего удивительного. У кукурузера, емнип, аппаратная поддержка декодирования h.265. Годы никого не щадят.
Да
Пизда
а куда оригиналы делись? экспорт данных гугла выдаёт оригиналы, как минимум 8-летние оригиналы ещё целы
Не тонем
Стандарт AVIF вроде окончательно принят, а никакой софт до сих пор в него не умеет или я плохо искал? Особенно интересно насколько лучше lossless сжатие в сравнении с webp
> софт до сих пор в него не умеет
Это. Только очень эпизодические звери.
>lossless сжатие
Все новые форматы фокусируются вокруг удаления избыточности. Нечё от них лослесс побед ждать. Юзай специализированный flif.
А где же поддержка всеми мировыми корпорациями, где же попенсорс с гитхаб-бинарниками от васянов...
>FLIF
У меня не взлетел, при конвертации полноэкранных пнг скриншотов во флиф файлы в основном были немного больше чем вебп лосслес. Последний к тому же быстрее открывается и имеет превьюшки в проводнике дриснятки. Для перегона юзал XnConvert, возможно там не те либы и можно получить результат получше
>или я плохо искал?
https://github.com/AOMediaCodec/av1-avif/wiki
пока мало что, да и то не всегда нормально работает, можно еще руками через Aomenc сжимать и потом муксить MP4Box
>Особенно интересно насколько лучше lossless сжатие в сравнении с webp
https://www.reddit.com/r/AV1/comments/aabqdc/lossless_compression_test_png_vs_webp_vs_avif/
когда то давно еще тестировали энтузиасты, но тут тоже много лишних действий нужно совершать для подачи кодировщику в нормальный для него вид и формат, вот табличка для примера
https://docs.google.com/spreadsheets/d/1bG-CSTn_L79MtS7A-wR572H5_W_3kb2xX5AWagKn1ak/edit#gid=0
>Юзай специализированный FLIF
Его автор уже пару лет помогает делать Jpeg XL и влил туда свои основные наработки с FLIF и позже его же FUIF, так что сразу лучше на него и смотреть https://gitlab.com/wg1/jpeg-xl
Последние билды под винду на doom9 обычно выкладывают:
https://forum.doom9.org/showthread.php?p=1901676#post1901676
Для lossless у него нужно выставлять качество 100 (-q 100), также он может пережимать Jpeg без потерь, в среднем на 22% (принятый в формат brunsli), можно глянуть онлайн, как это пашет - https://google.github.io/brunsli/
Зачем аноны хотят перекодировать свои паки с трапами в новый формат, если при каждом перекодировании качество ухудшается?
Потому что аноны идиоты.
Ничего не понимаю в этих шакалах.
Возможно на одном и том же видеотреке некоторую часть выполнить с большим качеством? Например, есть ролик с записью от видеорегистратора, где не очень важен некоторый тайминг перед аварийной ситуацией, но нужен для общей ситуации, а в некоторый момент качество увеличивается.
Возможно на одном и том же видеотреке некоторую часть выполнить с большим качеством? Например, есть ролик с записью от видеорегистратора, где не очень важен некоторый тайминг перед аварийной ситуацией, но нужен для общей ситуации, а в некоторый момент качество увеличивается.
Как сделать чтобы youtube-dl скачивал bestaudio и bestvideo, а потом ffmpeg склеивал это все в mp4/webm. а то у меня все в mkv склеивается
--merge-output-format
thx, anon
Делить на части, кодировать, склеивать.
--zones в x264
У ffmpeg можно квантование на лету менять, но я не помню как, слишком давно это было.
> У ffmpeg можно квантование на лету менять
Возможно вот это, но кажется другая команда была, это возможно старая команда, которую заменили.
> WebP
Сорта жипега от гугла. Выглядит как говно по сравнению с BPG.
>с BPG
BPG - мертворождён, можешь забыть про него.
Вместо него, с лёгкой руки эппла, пришёл по сути тот же HEIF.
И конечно же WebP проигрывает HEIF во многом. Во многом, кроме распространённости и поддержки в ПО.
>BPG - мертворождён
Так-то WebP тоже. К тому времени когда его поддержку добавят везде и им даже начнут пользоваться люди он станет ненужен из-за ширины канала и возможностей железа юзать повсеместно PNG, а аппаратная поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000 делают жопег и вовсе неубиваемым в обозримом будущем, это говно не утонет, прост в настройках шакалирование будут меньше пользовать. WebP мертворождённое говно, в попытке "пожать" сделали говнище, которое в затратах процессорного времени соревнуется с полноценными lossles (и обгоняет их), при этом ещё и качества не даёт.
>Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
Даже без учёта того, что у 3700u аппаратная поддержка H265 в видеоядре, он на клыка сэндику даёт. Там блядь оперативная память в два раза почти шустрее, инструкции новые и старый Гипертрединг времён Сэндика на фоне Скалейковского и Рузеновского гипертреда это говно.
Я сжал.
>К тому времени когда его поддержку добавят везде
Она сегодня и есть практически везде.
>поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000
А вот у этих нет и никогда не появится. Вот и вся история.
>Она сегодня и есть практически везде.
1. Если бы работал в веб макакинге, то знал бы, что он практически нигде не используется.
2. Я больше скажу, сам гугл в рот ебал свой WebP, используя исключительно SVG, PNG и JPG на своих сервисах, проще говоря, WebP не нужен даже Гулагу. Вот тебе пруф, можешь сам отинспектировать сервисы гугла, везде svg и png.
3. А теперь самое смешное, основное применение WebP по состоянию на 2020 год это пережатие уже уебански шакальных jpg с сайтов для онлайн конвертации и отдаче юзеру через CDN.
4. Apple Safari.
> сам гугл в рот ебал свой WebP
Он его для юзер-контента использует, превьюшки на ютубе, картинки/иконки в плейсторе
>превьюшки на ютубе
Лол, нет.
>картинки/иконки в плейсторе
Иконки - да. Часть картинки обложки, наложения кнопок плей и т.п. png.
Яндекс отдаёт предпросмотр картинок в webp, например.
А в плейсторе он оказывается отдает хрому вебп, а лисе пнг. Хотя с тем что вебп нинужен я согласен.
> Гипертрединг времён Сэндика на фоне Скалейковского
А что изменилось? По сравнению с смт все такое же сендиговно.
Для avif теперь выкладывают билды под винду, плюс завезли поддержку png https://ci.appveyor.com/project/louquillio/libavif/build/artifacts
Анон в /a/ помню год назад скидывал Evangelion 1.11 влезающий в 40 Mb двача, и при этом это можно было даже смотреть, фильм на полтора часа. Есть у кого этот файл?
Помню, что ширина кадра была аж 350
Что то странное происходит с 251-м opus на youtube.
Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.
Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.
Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
>144kbps
Ростелеком.
А почему вы спрашиваете?
Новый XnView MP с версии 0.96 читает/конвертирует AVIF.
Только он разожрался как не в себя. Подожду пока в nomcas впилят.
Куда? В nomacs?
А есть для опуса какие-нибудь костыли, которые анализируют mp3шный трек и исходя из его битрейта, частот и энтропии сами выбирают пресет для сжатия типа "чтоб примерно так же осталось"?
>nomcas
Тормозное говно какое-то. Хотя, это на винде, может быть.
> Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.
Нет, они похожи именно на мр3 стайл оставление только самых громких пиков свыше 16 КГц
Нахуй надо?
Чтобы пережимать звукан из mp3 в opus, внезапно.
А в чем планируемая польза от этого?
Чтобы итоговый файл занимал меньше места, вестимо.
Хех, мда. А не лучше будет скачать желаемый музон в флак, а потом пережать в опус желаемого битрейта? Избежишь двойной потери качества
Почему ты решил что это музыка, и что она существует в каком-то другом экземпляре? Двач ты не меняешься.
Это архивные записи разговоров, при том в огромном количестве, из разных источников и с разным качеством.
Я конечно могу засесть на две недели со слепым тестированием и подбором битрейта. Но хочется один такой ключик типа -mp3_like как тут который примерно оставит всё как есть, но позволит занимать меньше места.
lowpass фильтры не идеальны, и при громких пиках они оставляют мусор в спектре они не полностью их подавляют, так что они остаются в спектре с приглушенной амплитудой.
В принципе, их можно подавить средствами самого кодировщика, путем подбора квантователя для соответсвующей полосы частот так, что-бы этот мусор остался за порогом округления, но qaac почему-то этого не сделал.
А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон. А поскольку после lowpass фильтр не идеален и оставил после себя мусор, то opus взял и закодировал его как смог.
Для примера 2-й пикрелейтед mp3 320kbps. Здесь видно что спектр отфильтрован, но оставшийся сигнал имеет примерно ту-же громкость мощность, энергия, как оно правильно называется?, что и сигнал с другой полосы частот. Это и отличает фильтр в mp3 от просто lowpass фильтра.
А теперь снова посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
>пресет для сжатия типа "чтоб примерно так же осталось"
>mp3 в opus
Ты видимо не шаришь. MP3 и Opus это совершенно разные кодеки. У них общего только то что это lossy аудио кодеки.
Ты пробовал сравнивать AAC LC с HE-AAC (тот который с SBR)? Должно быть очевидно, что высокие частоты синтезированные из низких при той коррекции что там имеется не будет идентичным спектру AAC LC с более высоким битрейтом.
Начнем с того что opus произошел от аудиокодека Vorbis, очередного убийцы mp3, отличается патентной независимостью. Говорят, у него математика преобразования другая. А потому, ты не можешь запихнуть mp3 в Vorbis, только lossy перекодирование.
Opus же скорее ответ AAC, нежели MP3. И раз он выиграл в аудиофильских слепых тестах в 64kbps у HE-AAC, вероятно, у него есть нечто похожее на SBR, а именно: Band Folding. А потому, opus может тебе закодировать Full Band даже на 32 килобита в секунду (но криво, со слышимыми артефактами сжатия), а может даже меньше.
Подбор пресетов опуса под MP3 здесь не уместен, поскольку OPUS не режет частоты так, как это делает MP3. Это ты можешь делать на AAC LC или на Vorbis.
Единственный вариант юзать opus это конвертировать из lossless, или в крайнем случае MP3 CBR 320 kbps.
> lowpass фильтры не идеальны
Цифровые - идеальны)
> А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон
Ну он даже на 144 кбит/с на ютубе режет под 20 КГц (по моим тестам в фирефох-треде) (притом полный диапазон - 24 КГц)
> посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
Хотя да, но ослабление громкости слишком слабое
Хули толку. Большинство этих форматов здохнет, как и все технически более совершенные «убийцы» mp3, jpg, rar и т.д. Популярность и распространённость — вот что действительно важно.
Всем этим 7zip-ам, опусам и прочему jpeg2000 вечно ютиться на задворках интернетов, поддерживаемые на искусственной вентиляции лёгких силами трёх с половиной задротов. Мне, разумеется, тоже не нравится эта ситуация, когда привычка стоит на пути прогресса, но хули делать.
>Популярность и распространённость — вот что действительно важно.
heif - дефолтный формат айфонов, поддерживается практически всеми ОС. Как только браузеры научатся - вот тебе и наступит новый жипег.
HEVC не поддерживают принципиально. А HEIF, обертку под HEVC для картинок, значит поддержат?
>Как только
Ну ты понял.
>притом полный диапазон - 24 КГц
у него нет режима 44100кГц, поэтому он ресемплит до 48кГц.
а срез 20кГц на всех битрейтах (за исключением самых низких) это у него по дефолту.
>Цифровые - идеальны
Смотря какой фильтр. Вот lowpass фильтр у Audacity там срез максимум 48 децибел на октаву. Приходится многократно повторять этот фильтр,что-бы действительно срезать ВЧ.
В Аудишне FFT фильтр начисто срезает, если настроить соответствующе. И отдельный low-pass filter есть вроде бы
Какого хрена опус уже год не обновляется? Всё, кодек допилили до совершенства штоле?
А почему его должны часто обновлять? Тулсы вообще по несколько лет обновляются, tak вон с 2013 пилится, беты там какие-то. mpc с 2009, wavpack, flac раз в два-три года, это нормально, а народ продолжает массового поедать мертвый mp3, классика.
А если у меня исходник PCM в 44, то как быть? SOXом переводить исходник в PCM 48 и жать потом его в opus? или SOXом переводить уже готовый lossy opus 48 в 44, полученный из исходника PCM в 44? Opus вообще сможет в 44 кустарно c вышеописанным и есть ли в этом смысл/плюсы/минусы? Не понимаю в этом. Теряется ли качество из-за PCM 44 пережатый в opus 48, не считая естественной потери pcm->lossy, чисто за частоту дискретизации спрашиваю.
> почему его должны часто обновлять
Ну самый свежий из lossy вроде, только в 2012 формат запилили.
Гуглить то хоть пробовал? Никуда не делся твой opus, развивается.
https://git.xiph.org/?p=opus.git
https://git.xiph.org/?p=opus.git;a=log
Тут смотрел: https://opus-codec.org/
Ну в сам opusenc встроен ресемплер. Но если сомневаешься в его качестве, можешь и через sox перегнать.
Передискретизация, с учетом неидевльности lowpass фильтров, может вносить дополнительные искажения. Только вот являются ли они существенными при lossy компрессии?
По умалчанию opusdec такой сигнал снова отресемплит до 44100 Гц. А вот foobar2000 будет воспроизводить в 48 кГц без ресемплинга.
Ещё учти что звуковуха может нативно не поддержитать 44100 Гц. Тогда ей всё равно понадобится ресемплер.
> Ещё учти что звуковуха может нативно не поддержитать 44100 Гц
Все звуковухи реалтек передискретизируют всё аудио в 48 КГц, если в панели 48 стоит, насколько я понимаю.
>2k20
>сжатие
>сжатие
Во-первых лосслес в плане математики ультрапримитивен, там всё изобрели уже 30 лет назад. Чё его в 2к20 обсуждать?
Во-вторых, в 2k20 основной потребитель контента - это мобилки, где размер хранилища определяется маркетингом а не техпроцессами. Да даже компы сейчас стараются укомплектовывать ссд, а данные выносить на насы. Так что сжатие в 2к20 - более чем актуальная тема.
Как вам сжатие в тик токе?
Да ты же просто нищук.
Я тебе про ситуацию в экосистеме, а ты мне ad hominem про одного человека. Давай вкатывайся в формальную логику, пока не поздно.
Модус поненс
Купи нормальный телефон, а не сяоми, бомж.
На самом деле в 2017 году за 42К айфон имел 32 ГБ (и их не расширить MicroSD), а за 16К Сяоми - 64 ГБ, так что это айфоны обделены хранилищем
Ни в один флагман не удастся всунуть десяток терайбат, как в старую добрую пеку. Потому с раземером в любом случае приходится считаться.
Да как сука ебаные превью аудио+картинка делать
бурят приди порядок неведи!
бурят приди порядок неведи!
Вижу ты хорошо шаришь. Не мог бы пояснить еще пару моментов с PCM? С такими вопросами ньюфажин аудиофилы сразу гонят тряпками.
1) Достаточно ли ужимать 24-битные PCM в 16-битный PCM с обычным дизерингом фубара или нужны обязательно всякие нойзшепинги дополнительно для такого?
2) При конвертировании PCM Aiff в PCM Wav идентичной битности теряется ли качество? И тоже нужны ли в таких случаях конвертирования всякие дизеринги и тд/тп?
Я неон, но по 1) скажу, что твоя пекарня издает такой шум, что динамического диапазона 96 дБ даже с дитхерингом без нойз шейпинга выше крыши будет, ты весь этот диапазон не услышишь в условиях существенного фонового шума.
Только непонятно, зачем ужимать, у тебя звуковуха только вывод 16 бит что ли поддерживает? 24 нет?
Точнее, благодаря дитхерингу динамический диапазон даже больше, это уровень шума на -96 дБ
Но WebP на четвертой объективно хуже. У него же даже морщины разгладились, неужели ты этого не видишь? Типичная ошибка новичка в шакалинге - мыло вместо частичного сохранения деталей.
Да просто экономия места, музыки пиздец уже, в облако кидаю не часто прослушиваемые жанры. У меня интернет еще не особо то быстрый, выкачивать потом эти 24, я смысла в них особого не вижу, мне мастерингом не заниматься, бутлегов писать не планирую. А если нужно побаловаться, то всегда можно достать их из первоисточника, в данном случае Bandcamp.
https://bandcamp.com/fossf1/following/genres
https://bandcamp.com/fossf1/following/artists_and_labels
Ты просто глянь на списочек жанров, устанешь, а я всё это чекаю, покупаю, качаю, слежу.
Поясни за второй вопрос, вброшу что-нибудь
>пиздящий данные пользователей через метадату
Наркоман? Током ёбнуть?
А по второму вопросу - я забыл, что за aiff, в чем его особенности. Ну если идентичной битности, то какие могут быть потери? Наверное никаких
И дитхеринг наверное нинужен
>частичного сохранения деталей
Это не частичное сохраненение деталей. Это имитация деталей артефактами сжатия.
Не скажу, что это плохо, кстати.
Да это тот же PCM, только эппловский. Блин, раздражает немного что не все кодировщики его поддерживают и в таком случае сначала aif/aiff в wav жать приходится.
Так уж и быть, раздаю бесплатные подарки. Спасибо за инфу. https://www60.zippyshare.com/v/IHyIka4F/file.html
> Да это тот же PCM, только эппловский
ALAC жи есть, я как раз его юзаю, чтобы на афоню скинуть лосслесс музон в Apple Music. Эпловский аналог FLAC. Конвертирую в него из FLAC.
Спасибо)) играет
Да я в данном случае предпочитаю Wavpack, в нем есть неоспоримая фича когда нужна экономия места. Гибридный режим позволяет держать сразу lossless и lossy размером как любой другой lossless контейнер. То бишь возьмем твой трек ALAC, предположим размером 25мб и Wavpack тем же 25мб, в которые ужались сразу lossy и lossless и их общий размер составляет тот же 25мб. А в случае ALAC получится что к этим 25мб нужно еще прибавить ~10 для хранения lossy AAC, получится уже ~35. Я знаю что на FLAC тоже есть такое, но сторонними васянами написано и не уверен будет ли работать везде, уже жаловался народ на траблы. А в Wavpack это из коробки.
Что-то с кодировкой не то, перекодируй документ, если нужно, да там ничего важного не написано, просто комментарии для упрощения. Но хоть официально бесплатное и в любом формате.
Как научиться пользоваться архиваторами?
вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?
Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.
Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?
Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.
Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
Создаешь профиль по умолчанию в винрар с форматом архива Rar с максимальным сжатием, и если по одному не будешь файлы вытаскивать, то непрерывный архив
Православная это шебм4ретардс, ебаный пикабушник.
>FFmpeg
>пикабушник
>Православная это GUI для FFmpeg
совсем дебич? Пошел обратно на свой пикабу и больше не возращайся.
Есть 17гб фото в пнг. Чем можно существенно сжать без потери (или с минимальной потерей) в качестве?
Каво
жми в png-zip
Взгляни на небо, посмотри, там плывут облака
cwebp -z 9 -mt image.png -o image.webp
cwebp -z 9 -lossless -mt (без потерь)
cwebp -m 6 -z 9 -near_lossless 80 -mt (без визуальных потерь, чем меньше число -near_lossless, тем меньше результат, но больше потерь)
Если просто для хранения, то можно и BMF
https://www.compression.ru/ds/bmf_2_01.rar
Сам формат это не какой то стандарт, но это один из лучших сжимальщиков без потерь, сразу он PNG не понимает, надо предварительно сконвертировать например в PPM:
ffmpeg -i image.png image.ppm
Уже потом сжимать:
BMF.exe -s -O"image.bmf" "image.ppm"
Потестил.
Везде максимальное сжатие без потерь, кроме heic. В нем есть минимальные отклонения. Был бы вином, если бы не зеленил картинку, и нет нормальных приложений для просмотра.
JPC - LuraWave JPEG-2000 Format, без потерь и быстро, но мертвый.
AVIF - oche dolgo, даже в webp будет все конвертироваться ~30 часов.
Тут только нужно смотреть как конвертируется в AVIF и HEIC, скорее всего в yuv444/yuv422 (а это уже потери, как при цветовом преобразовании, так и сохраняется меньше самих цветов).
В AVIF настоящий lossless режим есть через https://github.com/AOMediaCodec/libavif
Avifenc --lossless
Для HEIC были какие то форки с RGB, но надо разбираться и размеры там будут существенно выше.
У Webp если недостаточно скорости, можно использовать настройки побыстрее, даже на них результаты вполне себе.
Можно еще посмотреть тесты, которые я кидал в другом треде https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/
Также там есть тест PNG оптимизаторов (в табе PNG), в Jpeg XL сжимать на максимальных настройках тоже будет очень медленно, да и сам формат пока еще развивается, вроде как уже стандартизировали, но есть вероятность что новые версии не распакуют старые пикчи, тут уж на свой риск.
>В AVIF настоящий lossless режим
Он всё равно в yuv444 перегоняет.
Он также в них сохраняет дополнительные данные для обратного преобразования без потерь в RGB, можно почитать объяснение автора на реддите:
https://www.reddit.com/r/AV1/comments/gdi12d/libavif_v073_tagged_including_native_lossless_mode/fplg9s0/
шебм хуйня, не перематывается
Как максимально жать в лосслесс авиф? Пробовал "avifenc -l -s 0 image.png image.avif" с этой пикчей , но результат весит больше, чем лосслесс вебп.
xnconvert
Что у тебя за калькулятор?
Так и жать, если нужен настоящий Lossless, все остальные утилиты жмут в yuv444 не сохраняя дополнительные данные с RGB (можно точно также как они сжимать и avifenc, указав нулевой квантайзер --min 0, но не добавляя lossless). AVIF вообще не особо предназначен для конвертации чего то с RGB в lossless, т.к. у него все это сделано через костыли и очень сильно страдает сжатие.
Некоторые цитаты:
>I don't have any numbers to know whether this is normal or not, but AV1 is designed for lossy encoding, so it is possible. In order to have true lossless RGB, GBR planes are handed to the AV1 encoder, which probably causes the encoder to be less efficient than it could be.
(jdrago)
>YUV444 is not actually lossless. Conversion of 8-bit RGB to 8-bit YCbCr reduces the number of colors from ~16m to ~4m. You're basically not encoding the least significant bits in the red and blue channels - and those are typically high-entropy bits, so you get a close to 2bpp advantage by not encoding them.
(jonsneyers)
Кек, а в ноклу 808 из доисторического 2012 можно хоть 2 терабайта карточку засунуть как родную, которых до сих пор не выпустили.
только скорость будет 10 мегов/с
Как одной строчкой команд, а не кучей заходов в ffmpeg нарезать шебмку из огромного fullhd 60fps стрима h264/aac adts, получив на выходе например 640х360 vp9 512kbit / opus 64kbit моно с нормализацией под -1 дБ и срезом частот ниже 20 Гц? Скажем слепить 20 кусочков где-то в районе 04:23:40 - 04:24:02 и 07:45:21 - 07:48:54, в идеале ещё и вырезать из фуллхд оригинала кусок 640х360 в нижнем правом углу и засунуть его в финальный шебм. И всё это сразу одной строкой в консолечке. Чот получится наверно пердолинг не хуже установки генту.
>дополнительные данные с RGB
Понятно, откуда лишний вес.
нихуя не понимаю, нахуя рекомендовать heic / avif?
Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.
Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.
Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.
Впизду я ебал такой пиздец. Вы ебанутые.
Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.
всё кроме webp не выдерживает никакой блядь критики.
Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.
Вопрос - нахуя он нужен?
Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.
Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.
Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.
Впизду я ебал такой пиздец. Вы ебанутые.
Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.
всё кроме webp не выдерживает никакой блядь критики.
Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.
Вопрос - нахуя он нужен?
Какой видеокодек жмёт круче всех, чтоб весило хуйню, а качество было неотличимо от оригинала?
> времени обработки, конвертации, сжатия
Что, даже на 9900к сраные картиночки жмутся часами?
Прошу прощёния если уже было.
Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
x264
Ну бляя, отступы
Отступы там - самый из незначительных грехов. Он нигде не определяет рабочую папку, потому если запустить скрипт типа ~/scripts/myyobaffmpegwrapper/yoba.sh, то они пидорнёт случайный трек и картинку с хомяка.
Спасибо за замечания
>2020
>vp8
>vorbis
Лучше сначала просто перегнать гифку в видео, а после объединить с музычкой:
ffmpeg -i audio.mp3 -stream_loop -1 -i video.webm -c:a libopus -b:a 64k -c:v copy -shortest output.webm
А эта хрень работает с многопотоком? Похоже она только одно ядро загружает. :с
Можешь -threads 16 добавить, но объединение и так быстро происходит.
Стоит так же заметить, что при таком способе размер файла будет больше.
А если надо файл гигов так на 24 перекодировать?
С vp9 почему-то добавляется тишина в конец.
Открытый же
>9900k
Не, у меня не 9900k конечно же.
Но i5, довольно производительный.
Поэтому я хз, это нихуя не норма.
Записываю окно с ffmpeg -f framerate 60 -i -title "window_name" -c:v h264_nvenc -qp 0 output.mkv. Курсор двигается, но окно заморожено. Если с такими же параметрами записывать весь экран, то все норм. Чяднт?
Чем ваши webpы открывать?
браузером
Gwenview
HoneyView
> HEIC
Лол, ты чем жал? Я через ffmpeg + паковщик (gac) минимум по 10% получал, даже с суперужатых пикч с вк. Если ты не в состоянии понять как оно работает, это не значит, что оно не работает.
Не завезли ещё поддержку, гружу сюда.
https://files.catbox.moe/znx8on.heic
Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу inb4: слепой.
Кодировалось это всё на slow 4 секунды. На placebo 15.
Делюсь скриптом для красноглазых:
https://pastebin.com/9pwb2kNb
А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
> gac
gpac*
Котаны, возможен ли в принципе горизонтальный флип (т.е. зеркальное отображение) видео без пережатия? Ну или как и чем это сделать с минимальными потерями?
Метадатой дописать hflip, например?
https://it-handbook.ru/windows/povorot-mp4-video-s-pomoshhyu-ffmpeg.html
А, сорь, только сейчас посмотрел что не то кинул.
Вот тут чувак флипает метадатой и судя по всему мало какие плееры проигрываю его хотелки: https://superuser.com/questions/1393880/edit-mp4-hex-data-to-vertically-or-horizontally-flip-video-in-a-lossless-manner
Соус музыки из первой вебм?
crypt of the necrodancer
>минимум по 10% получал, даже с суперужатых пикч с вк
Только такая конвертация не имеет смысла, выигрывается мало, а потери при повторном будут всегда, даже в такой же или чуть больший размер
>Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу
Разницу видно, в основном сожрало все детали, но это ладно, бывает что нужна просто фотка поменьше без сильных артефактов
Но если такие потери устраивают, вот для примера WebP даже чуть меньшего размера чем этот HEIC https://files.catbox.moe/uukfg3.webp
(с ним тоже скорей всего разницы не будет видно, а учитывая что у HEIC никогда не будет поддержки в популярных браузерах из-за своих жестких патентов, то смысл все в него все переводить)
Жму аудиокниги и подкасты в opus VBR 56 (ниже уже явное говно и если в книге есть музычка, то лают шакалы). Жал лёгкий тихий джаз для прикола в CBR 64 - охуел от того, что на слух сложно отличить от исходника. Более насыщенная и громкая музыка типа митола естественно рассыпается в говно даже на 128. Всю коллекцию музла из mp3 320 и флака перегнал в ogg vorbis 192, остался доволен.
Всё правильно делаю?
Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
Всё правильно делаю?
Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
> начал с опуса, закончил ворбисом
> пережал из лосси mp3 в лосси ворбис
> Всё правильно делаю?
Ну как сказать. Я согласен, что 192 опуса с ютуба находиться на одном уроне с 320 мр3, но пережимать лосси в лосии - такая себе затея. Потери накапливаются.
Твоё право, если ты разницы не слышишь. Главное это своё говно пережатое потом среди других не распространяй.
> Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг.
Начни с webp. Незначительно проигрывает heif, зато быстр и поддерживается уже практически всеми тостерами.
Алсо если реально ЧБ а не оттенки серого, то можно много выиграть путём принудительной индексации и пнг-оптимизации. Но тут смотреть реальные примеры надо.
Ты на чем это слушаешь? На динамике лэптопа?
>пережал из лосси mp3 в лосси ворбис
320 мп3 это очень хорошее качество, которое от лосслеса хуй кто отличит в принципе. Ну может пара миллионов уникумов на всей планете с феноменальным слухом что-то будут подозревать. Пережимал чтобы место освободить (сотни гигов).
>такая себе затея. Потери накапливаются.
В курсе.
>Твоё право, если ты разницы не слышишь.
Либо не слышу, либо отказываюсь верить, что есть какая-то разница. Музыкант+звукач, зарабатываю этим деньги, со слухом всё ок, всё ещё могу слышать 19500Гц, хотя уже бородат.
> Главное это своё говно пережатое потом среди других не распространяй.
Не понял этого. Зачем я буду свою личную коллекцию музла где-то распространять?
>Начни с webp
Попробую.
>heif
XnConvert почему-то ошибку выдаёт, "файл не является изображением". Через что ещё попробовать?
Попробую, спасибо.
Слишком толсто. Сосите хуй, пожалуйста.
>Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете?
Если не так срочно нужна поддержка везде, то можно подождать Jpeg XL, у него очень хорошее lossless сжатие (для перегона пикч с PNG, иногда чуть хуже FLIF, но вот только FLIF существенно медленней, на декодирование даже в десятки раз и он заброшен) и плюс к этому можно уменьшить обычные Jpeg на 20-23% совсем без потерь (пример в онлайне https://google.github.io/brunsli/), ну а с потерями и еще больше.
В другие форматы уже такое себе, ну разве что еще в WebP есть вариант PNG пережать без потерь (все остальное или плохо жмет в lossless или очень медленно), а вот Jpegи пусть лежат, они все таки обычно поменьше PNG весят, да и каждый раз дополнительные потери будут (выйдет еще какой то новый формат и опять захочется пережимать, еще больше все зашакаливая, ну или искать все эти исходники)
>начал с опуса, закончил ворбисом
Озадачил ты меня этой фразой, решил проверить. Взял исходник в wav, пережал в vorbis 192 и opus 128, чтобы их размеры были примерно одинаковые. Закинул все 3 в давку и начал сравнивать, пуская в противофазу, ну и хули, как и ожидал - vorbis срезает ультра-высокие как обычно, в противофазе слышно исключительно шипящие, а opus вырезает вообще по всему спектру по чуть-чуть и в противофазе с wav слышно разницу вплоть до суб-низов, но высокочастотное шипение и на vorbis и на opus примерно одинаковое. Вот хуй знает, что из этого лучше - чуть больший срез высоких у vorbis с сохранением всего остального или вырезание по всему спектру у opus.
Ну так. Огг - это всего лишь контейнер. А ворбис и опус - совершенно разные кодеки из разных эпох с разными задачами.
Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа. Плюс апконвертит в 48000, потому лучше на родной частоте и сравнивать.
Ну и чисто моё мнение. Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass "режьте всех кто выше 18к, господь разберётся где свои".
>с разными задачами
Ну вот поэтому я и пережал всю музыку в vorbis 192, а аудиокниги в opus 56 VBR, потому что opus реально круто себя ведёт на таких низких битрейтах и голос в книгах не превращается в глухое бульканье как с другими кодеками.
>Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа.
Вот про это не знал. Попробую.
>Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass
Скорее вопрос вкуса, да и для разной музыки разный подход скорее нужен. Наверное если прогнать пару десятков очень разных жанров через спек, то обнаружится, что в половине из них информация выше 16-17КГц вообще отсутствует.
Запарился, короче, вопросом перешакаливания жипега в хеиф. Нашкалил жипегов от q100 до q4, затем каждый пожал хейфом от 100 до 1 и поссчитал ssim по отношению к несжатому оригналу. Ну вот какие выводы просятся:
1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.
2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.
3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.
Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.
2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.
3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.
Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
Ленка
Аниме, потому что многим тут важно знать
чем жмёшь в heif?
Шакалы, шакалы евривер.
где?
>А avif говно, тут согласен. Полчаса одну картинку обрабатывает.
Так нехуй выкручивать speed на ноль. Оставляй дефолтное значение, можно ещё jobs выставить по количеству потоков проца.
Существуют ли енкодеры в опус с ГПУ ускорением?
Обнаружил что у меня была старая версия опуса в гуй-мокропиське. Скачал последнюю, воткнул, заебись. Аудиокниги в 28 VBR охуительно кодируются. Если ниже, то Ш и С начинают люто шуметь, при этом на ультра-высоких добавляется какой-то рваный шум, будто биткрашер навесили.
нет и не могут существовать
>не могут существовать
Интересно обоснование этого тезиса.
Почему макак не запилит автоматическое пожатие картинок в ЖИПЕГ? С возможностью покрутить качество или вообще не пожимать, примерно как в дашчане. Заебали картинки в 15 метров.
Проблемы замкадска москвича не ебут
> Интересно обоснование этого тезиса.
Может быть бы ты загуглил?
https://minds.wisconsin.edu/bitstream/handle/1793/45041/ECE%20790%20Hsin-Yu%20Chen%20project%20Report.pdf?sequence=1&isAllowed=y
Но есть некоторые: НО.
То, что он описывает по поводу памяти и синхронизации между КПУ и ГПУ - я не могу сказать что и не актуально, и что актуально.
Т.е. изменения с момента публикации исследования в GPU были, да и производительность увеличилась раз так в 500+ плюс память так же быстрее стала, не говоря о чипах и так далее...
Но и процы тоже быстрее стали на самом деле, не в 500+ раз, но в раз 5+ точно...
это петушиное кукрекание про прогресс
>Популярность и распространённость — вот что действительно важно
Ты понимаешь, что "популярность", это быть одним из первых и лучших в чем-то и не сдаваться до конца. А не стек технологий...
это касается вообще всего о чем ты слышал:
nginx
winrar
kaspersky
norton
windows
debian
ubuntu
да любой популярный (очень популярный) софт возьми...
Тот же AIMP...
Я очень хорошо помню как он появился...
Он появился когда уже WinAMP всех заебал.
Аимп выглядел свежо, дохуя фич было, реально мощная альтернатива была всяким jetPlayer, Light Alloy, и так далее...
Тем более WinAMP... В ту же пору появился и deadbeaf кстати...
Даунич? Опус в ютубе и спотифае.
решил пожать wmv порнуху, старую, закодированную хуево.
Пытался решить проблему с:
- ffmpeg (чистым, и батниками) - FAILED
- handbrake -> FAILED
- xilsoft -> failed
- movavi converter -> failed
- wondershare uni converter -> failed
- ffmpeg batch converter -> failed
- Any Video Converter -> failed
- Media converter -> failed
Что значит failed?
Нужн понимать что под этим слово кроется неудача в одном из способов решения проблемы:
1.) нужно закодировать одновременно все файлы, а не выбирать по одному.
2.) нужно использовать haccels т.е. hardware acceleration, и дохуя (или почти все) - фейлили с этим.
3.) нужно без мозгоебли и пердоленья закодировать всё, что бы просто было и понятно всё, что есть куда кодировать, и что получим в результате. Тупо почти все слились в этом плане
4.) нужен автоматический подбор оптимальных параметров по видео, что бы кодирование происходило эффективно оставляя похожее качество но с меньшим размером.
5.) само собой не сжатый саунд нужно кодировать в эффективные aac / opus, с этой задачей овердохуя тоже не справилось.
6.) нужно что бы задействовалась видюха полноценно, а не на 3-5%, как в handbrake
7.) идеально что бы и встройка напрягалась
8.) нужно сохранять либо рядом либо в другой папке все сброшенные видосы.
И вот мы подобрались к тому, что только одна софтина справилась с этим всем -> FormatFactory.
Поэтому да - я рекламирую её, как годноту которая просто работает из коробки и делает всё что лично мне было необходимо для 100гб архива прона выкаченного с порнолаба.
Результаты - несколько часов ебли.
Около часа конввертация
В результате получил на 64% меньше размер (36гб, против 102 изначально), при том же качестве визуально видео и аудио.
Аноны, есть ли в ffmpeg возможность сделать максимально компактный видеоролик по схеме?
1. Вступление ролик1
2. Цикл ролик2
3. Окончание ролик3
Видел, что зацикливали анимации без увеличения объема, а такое можно?
1. Вступление ролик1
2. Цикл ролик2
3. Окончание ролик3
Видел, что зацикливали анимации без увеличения объема, а такое можно?
Хуею в винрарщиков, при наличии охуенного и открытого 7z
У него гуй и интеграция в систему говно.
Причем тут это?
Вот же делали зацикленный клип без потери прстанства
Можно ли сделать то же самое, но с вступительным блоком и завершающим?
>Причем тут это?
При том, что ответ был на другой пост.
>Видел, что зацикливали анимации без увеличения объема
Где?
фапБ ебучее мыло
Ну вот же
Там не зацикливание, а один монолитный видеопоток.
Понятно. Только этот поток не занимает пространство, т.к. один фрагмент повторяется на протяжении всего ролика. Я на 100% уверен, что кодек позволяет нелинейно ссылаться на кадры и можно собрать ролик из циклических фрагментов, которые будут занимать только свой кусок пространства, а не копироваться на весь клип.
Только как это сделать я не знаю, вот и спросил.
>при наличии охуенного и открытого 7z
Который настолько охуенен, что целиком распидорашивается от малейшей битовой ошибки.
> малейшей битовой ошибки.
Так-то да, 7z не умеет, но для подавляющего количества задач это не требуется.
А ты сам где это реально применяешь?
Из-за этой хуйни перестал бэкапы жать в 7z. Потому что бэкапы на каком только говне не хранятся.
Когда уже вымрут все использующие i и j в циклах вместо осмысленных имён.
> целиком распидорашивается от малейшей битовой ошибки
Про такой параметр как размер блока в курсе? Или ты там опять базу данных в единственном экземпляре в режиме непрерывного сжатия жал?
Погонял avif на манге, заебись жмёт. Правда времени дохуя уходит и оперативку забивает моментально, но это не главное. Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.
По шкале квантизации от 0 до 63:
Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.
Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.
Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.
Но если на 50-55 жать цветные, то шакалы просто пиздец.
И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
По шкале квантизации от 0 до 63:
Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.
Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.
Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.
Но если на 50-55 жать цветные, то шакалы просто пиздец.
И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
>Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.
Надо ещё и размер пикчи учитывать.
Нашкрептах за пять менут. Имаджмагик может посчитать тебе гистограмму, если на ней буду цвета отличные от серого то картинка цветная. Ну и разрешение так же.
Господа шакалы, посоветуйте, в какой lossy кодек лучше жать музыку - aac-lc или opus? А может что-то другое? Нужна хорошая поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом. Кроме того, интересно, насколько сильно накапливаются искажения при пережатии из mp3 320k?
Из mp3 320 можешь жать во что угодно без задней мысли.
По остальным:
aac - на самом деле не так хорош, как принято считать. На низких битрейтах превращается в говно.
opus - можно жать лёгкое музло в 96 vbr, если места жалко. В 128 vbr или даже выше жми любое музло со спокойной душой, разницу с флаком услышат три с половиной аудиофила на оборудовании за квадриллион баксов.
vorbis - на 160-192 vbr отлично жмёт и сохраняет спектр (ниже 160 - обрезка высоких начинается), вариативность битрейта на vbr высокая, где надо - добавлет сколько нужно, где не надо - экономит.
Разница между opus и vorbis - первый вырезает понемногу из всего спектра с упором на высокие, второй режет начиная с ультра высоких, не трогая всё остальное. Сам решай, что тебе важнее. Хотя на указанных выше битрейтах разницы реально никакой. Поддержку тэгов сам проверь. Поставь сам знаешь откуда конвертер xrecode II, жми и смотри. Только для опуса кодек обнови, с https://opus-codec.org/downloads/ -> opus-tools 0.2 (Opus 1.3) -> оттуда файл opusenc.exe достань и засунь туда, где такой же лежит внутри папки xrecode II, замени. Или купи прогу за 15 баксов, там уже третья версия вышла.
>поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом
foobar2000
Потестировал, шиндовс 10 из коробки до сих пор не умеет в теги vorbis (хотя полная поддержка opus добавлена год назад), на андроиде с этим тоже есть некоторые проблемы (везде решается установкой стороннего плеера). Наверное, всё же буду жать в AAC, с ним нигде нет проблем, а на качество на низком битрейте мне всё равно, т. к. музыку жму в 256k vbr (мне не нужно максимальное сжатие, просто что-то лучше древнего mp3 и его чехарды с тегами).
Не тонем
>mp3 320k -> aac 256k
А смысл? Если уж пережимать так хотя-бы в 160k, если не меньше.
нет смысла никакого.
Мимо, анон который пережал огромный архив музла в разные форматы, а теперь страдает от этого. Потому что нигде, кроме плеера эти форматы и нахуй не нужны.
Тоже касается и фото.
Хранить что-то в современных форматах можно лишь для АРХИВАЦИИ, но не как файлы, которыми изредка, да пользуешься, тем более если пользуешься регулярно. Ебли дохуища.
>лишь для АРХИВАЦИИ
>кроме плеера эти форматы и нахуй не нужны
у плееров память не резиновая, ты как бы сам должен это знать, раз юзаеш. У телефонов и смартфонов как бы тоже. но те хотя-бы aac поддерживают (кроме артефактов древности), а смартфоны на android ещё и в opus могут.
Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим
>если уж пережимать так хотя-бы в 160k, если не меньше
лол. разочарую вас, наверное, но такой клоунады lossy релизов в интернетах/сервисах - везде и всюду.
Я не вижу в этом сложностей, популярные плееры поддерживают это из коробки, как пекарен, так и мобильные. Да и музыка и так и сяк только в плеерах используется, где еще то и зачем.
У тебя устаревшая, последняя это 1.3.1. Да и смысл шареварь ставить, когда достаточно конвертера в фубаре, добавив его же пересобранные энкодеры/декодеры, которые тоже станут работать как на некропекарнях, так и на новых, в этом и вся их разница над официальными.
На худой конец можно и мокрую письку поставить http://www.foveon.de/sonstiges/opusdrop/ , которая еще и сэкономит время, просто закинул в окно и готово.
По сабжу - кому важен lossless на максимальном сжатии, рекомендую tak. гуй уже из коробки, жмет сильнее всех остальных и вдобавок быстрее. Имеет вариативные режимы , от потоков до оптимизаций под процессоры, как некропекарен, так и новых, чтоб еще быстрее было. Кому хочется потестить - скачайте этот релиз в wav https://truthradio.bandcamp.com/album/- жмите во flac с максимальным -8 --keep-foreign-metadata. а так же в tak с максимальным p4m. Разница в общем размере релиза будет в 182 и 160. Если кто-то держит такое в облаке для исходников, то ради экономии может и сгодится. Да и не имеет проблем с этой потерей байтов, которые большинство не учитывают, не используя --keep-foreign-metadata во flac. в результате чего размер от исходного потом отличается, то бишь уже не точная распаковка. Это самый дерьмовый минус у flac. В tak такого нет.
Еще как вариант, можно использовать гибридный режим у WavPack, который в общий размер ужмет lossy и lossless версии. Тоже очень экономная штука, ибо не надо добавлять лишние мегайбайты для случаев хранения релиза в lossy + lossless версий. Суть в чем? flac/lossless 21мб + mp3/opus 7мб = 28 в облаке. или же гибридный wavpack 21мб, в котором уже хранятся обе версии со своим собственным форматом. И это только один трек был, а теперь посчитаем все десять. Неплохая фича для неосиляторов, кто не видит/не слышит разницы в форматах, но ужимать/экономить место хочет (но это только при условии что исходник ему тоже важен для хранения. впрочем, можно и просто для lossy wavpack использовать, так как еще и битность не теряет, да и по тестам интересен. просто малоизвестный формат, который не только в lossless умеет).
вы не понимаете нихуя.
Пишу ещё раз. Смысл имеет только архивация для хранения, либо максимум для воспроизведения, не более (и то, с проблемами).
Я пережал огромную библиотеку медиа-файлов которые я слушаю\смотрю\читаю\просматриваю.
Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу. Потому что даже современное лицензионное ПО не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Всё остальное - впизду, нахуй блядь.
>Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу
Сам ты нипанимаеш. Ты сел на жопу не потому что форматы плохие, и даже не из-за кривого ентерпрайзного софта, а потому что ты lossless исходники удалил без бекапа. Страдай теперь, сам виноват.
Имплаинг что кто-то кроме 0.01% потенциальной аудитории на ютубе заметит разницу, если в клип воткнуть 3 раза пережатый звук. Лишние проблемы себе создаёшь на ровном месте.
>не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.
Ну так пережми обратно в поддерживаемые форматы и отложи в сторонку, на время работы, а потом удали нахуй. В чём проблема-то? Или аудиофил дохуя?
ОДИННАДЦАТЬ ЧАСОВ
https://youtu.be/B-w03icSDFE?t=328
https://youtu.be/B-w03icSDFE?t=328
Ради интереса сравнил MP3 (lame), AAC-LC (qaac), Vorbis (libvorbis) Opus (libopus). Кодировал Rammstein - Ich Will и Gorillaz - Clint Eastwood, 64kbit, все кодеки в режиме VBR. Для Gorillaz - Opus, Vorbis, AAC-LC>говно>MP3. Раммштайн, судя по всему, был сложнее для сжатия, поэтому Opus>Vorbis>моча>AAC-LC>говно>MP3. Надо отметить, что AAC-LC не очень жалует высокие частоты при сложной композиции, а также все кодеки, кроме MP3, работали с частотой дискретизации 44100 и выше.
Хуле ебало скорчил? Я слона 16 часов кодировал.
Круто чё, теперь даже африканские дети смогут оценить отечественный кинематограф
Ну да, всё правильно. В митоле очень высокая плотность высоких частот из-за гитар с дисторшеном и громких железок. Поэтому все лосси кодеки жиденько обсираются при недостаточном битрейте. Для себя нашёл минимум для митола и всякой сложной электроники - 96 VBR Opus и 160 VBR Vorbis. Ниже - на опусе начинается сужение стерео на высоких частотах (широкие тарелки, например, начинают звучать ближе к центру, теряется пространство), а на ворбисе ниже 160 начинают обрезаться ультра-высокие (можно заморочиться и посмотреть каждый битрей через spek).
Всю жизнь кинчики оставляли сжимать на ночь, тоже мне срок. Когда речь идёт о "сжал один раз" - "скачал миллион раз" то как вполне себе затраты окупаются.
А вас не смущает перманентный апсэмпл из 44 в 48 в опусе? Это вообще хорошо для качества? Хочу определиться с форматом, но вызывает вопросы. mp3/aac отпадают.
>Это вообще хорошо для качества?
Это похуй для качества. Не забивай голову аудиофильскими бреднями.
мимо-звукач
Для lossy формата это похуй для качества. Ты от сжатия больше теряешь, чем от передискретизации.
не знаю, как я сюда попал но на всякий случай спрошу
как порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
как порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
Сама передискретизации в большую сторону - операция без потерь, спасибо за это Котельникову.
Проблема в том что после передискретизации происходит повторное квантование. Но на фоне сжатия - это потери ультрамилипиздрические. Что-то уровня дроча на джиттер-коррекцию. Можешь не забивать голову.
cue файл есть?
Cue файл вбрасывай в фубар, увидишь треки, выделяешь их и жмешь конвертацию в нужный тебе формат. Для поносного апе в фубар еще и плагин ставить нужно, да и сам апе лучше на "так" заменить - лучше и не столь требователен, быстрее сделает. А раз плеер не поддерживает, то надо выбирать кастомный режим, прописывать путь до mac.exe и вводить нужные ключи вручную, а их еще надо знать. Сам mac.exe еще и скачать нужно, а официально он только в виде инсталятора есть, что тоже ебанутость. Я не советую этот формат, никаких плюсов, пережми его в любой другой, какой нравится.
А можешь просто CUE Tools поставить, это гораздо проще к освоению и ничего уже не требует.
Сделал наглядный тест аудиокодеков
все ясно!
Удалил и забыл. Пусть сами ебутся со своим обезьяньим говном.
aac ожидаемо соснул у opus и vorbis на 64kbps. Хотя для митала ни тот ни другой на таком низком битрейте не подходит, тарелки и гитары теряют ширину резко.
>митала
нинужная хуета
Надо заметить, что здесь используется профиль Low Complexity (LC), который не использует специальные фильтры для низких битрейтов.
Лет через 10, когда будет работать на любой микроволновке, ухх заживём!
Объясните чайнику, пожалуйста
Что лучше 264 или 265? Важно, впрочем, качество приближенное к оригинальналу.
Просто только недавно об этом вообще услышал.
И пиздец статьи и статьи, столько инфы, а нахуй ничего не понятно
264 быстрее, 265 лучше жмет
На качество кадров не влияет, никак?
> 265 лучше жмет
нужно читать как
> при одинаковом размере файлов 264 будет выглядеть хуёвее
Православная утилита кодирования - FFmpeg:
https://www.ffmpeg.org/
Вики по использованию :
http://trac.ffmpeg.org/wiki
GUI - FFmpeg Batch:
https://sourceforge.net/projects/ffmpeg-batch/