Унижаем PNG-блядей, ждем ввода WebP и AV1, пишем Нариману Абу в /d/, отправляем на свалку H264/vp8, кодируем минутный ШебМ джва часа.Православная утилита кодирования - FFmpeg: https://www.ffmpeg.org/Вики по использованию :http://trac.ffmpeg.org/wikiGUI - FFmpeg Batch:https://sourceforge.net/projects/ffmpeg-batch/
Третьего дня по совету проверенного поискового гиганта эксперементирую с новым мегаформатом webp, задыхаясь от жадности к хранилищу, перекодировал пак трапов. Размер и качество, мое почтение, хорошо сделали. Кроме того, удаление шумов и артефактов приятно щекочет простату. Был решительно готов закодировать все фото, однако, малолетнему кодеру невдомек, что метаданные удалять не стои. Как побороть проблему?
>>2686616когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же было, хотя вебмы действительно более значимы.
>>2686610 (OP)> WebP Очередной зонд пиздящий данные пользователей через метадату. Хотя что еще ожидать от компании специализирующейся на ботнетах.
>>2686989учитывая что для vp9 нет хардварного энкодинга на gpu, HEVC сжимается хардварно на огромном количестве видимокарт, а сжатие vp9 занимает овердохуя времени имею сказать следующее - ебитес врот своим vp9av1 ваще нахуй нинужон, по тем же причинам
>>2686610 (OP)Новые люди, новое время, когда то по моим алгоритмом работало сжатие, один раз мы пытались сжать ядро планет, что бы получать неограниченное тепло, но математические алгоритмы не сработали!
>>2686610 (OP)Вся суть вебп одной картинкой. Меньше артефактов - меньше деталей.Алсо вебп, в отличие от того же heif не умеет в градиенты.
>>2687664>меньше деталей.Нет.> Алсо вебп, в отличие от того же heifНе опенсорс, уноси.>не умеет в градиенты.Эм что?
>>2687799Как этот хентай можно сравнивать с божественным вебпом?? Все детали жпега - это артефактная лестница
>>2688727Имитировать детали артефактами, например? 30 лет так живём уже. Можно было бы анализировать картинку и по маске псевдослучайный шум перлина натягивать, чтобы этой кожи младенца не было.
>>2688736Короче свёл исвудыча, чтобы размеры были одинаковые.8576 clee.jpg (jpegoptim --size=8k)8522 clee-26.webp (cwebp -q 26)8251 clee-28.heif (heif-enc -q 28)
>>2688759Мыло нужно видемокодекам, чтобы вектора движения долго можно было использовать и не накапливать ошибку.В статических кодеках рулят другие принципы.
>>2688758Последний эксперимент: даунскел до 0.5, webp оптимизация до 8282 байт (-q 78) и последующий апскел через ESRGAN.
Говорят, что ав1 будет лучше хевка. Что-то мне сдается, что это пиздеж. Даже хевк против х264 хуже в плане детализации. Сужу по примерам аниме, неоднократно делал сравнения.
>>2689813Случайная фотка из инета была. Не гарантирую, что он предварительно не был пожат.>>2689773> А размер точно одинаковый? Размеры подписал. HEIF даже чуть меньше:webp - 8522 байтheif - 8251 байт
>>2688538>>2687876Короче енкодер avif я нашёл тут: https://github.com/Kagami/go-avif/releasesГде бы теперь декодер найти, чтобы без конпеляции и пердолинга?
Забил короче на avif, оставил jpg, webp и heif. Скрипт берёт картинку и жмёт тремя разными кодеками до одинакового размера. Тут глаз в 4, 6, 8 и 10 кб.
>>2692145Здесь heif закодировал больше всего деталей, хотя заметны мазки внутрикадрового предсказанияheif > webp > jpeg>>2692148Здесь heif сосёт.Лицо как у куклы, выглядит пластмассово. Гиганские блоки с явными арктефактами звона. Внутрикадровый предиткор превратил брови в прямые линии.webp > heif > jpeg
>>2694527>>2692148Когда писал тот пост не обратил внимания на размер. А там же jpeg и webp по 2 мегабайта весят, а heif 1 мбайт. Так сравнивать нечестно. Переделывай.
>>2686610 (OP)Забыли ссылку на гайд по webm кодированию в шапку треда добавитьhttps://github.com/pituz/webm-thread/wiki/webm-encoding
>>2694531>Переделывай. Эта картинка была вручную была собрана из максимально сжатых вариантов, не сравнивай по ней, сравнивай по 3к варианту.> webp > jpegНасчёт этого бы поспорил. Чисто внешне по количеству деталей webp тот же жипег, но у жипега артефакты уже приелись, а webpшное мыло реально глаза мозолит.
>>2695096>жипега артефакты уже приелись, а webpшное мыло реально глаза мозолитто есть тебя не смущает убитая цветопередача вследствии задранного квантователя и примитивного алгоритма компрессии.Как по мне вместо хранения ВЧ квантованных до металлического звона лучше срезать их НЧ фильтром и сохранить изображение в меньшем разрешении.WEBP хотя бы пытается замаскировать блочность, как и h264 и всё что после него.Главная проблема webp в том, что там даже не vp9, а устаревший vp8. Ещё одна проблема этого формата в том, что хоть там и взяли за основу видеокодек vp8, но анимации он сжимает только intra фреймами. Из-за этого гифки сжимаются в лучшем случае на 50%. Поэтому я в 2019м кодирую гифки в неудобный для infinite-loop анимаций формат webm.Еще сейчас набирает популярность формат apng. Это lossless формат, который сжимает гифки на 5%. Да, у него есть преимущество перед gif, так как он может закодировать true color анимации без потерь, да еще и с настоящим альфа каналом. Но большинство гифок это нарезки из фильмов, зашумленные дизерингом из-за ограничения в 256 цветов на одном фрейме, и там это lossless кодирование не нужно в принципе.
>>2695497>apngДля этой хуйни уже появились оптимизаторы, затирающие повторяющиеся части у последующих кадров?
>>2686610 (OP)>4 пикЕсли не рассматривать картинку увеличенной в близи, то, ЖПЕГ безоговорочно лучше, больше деталей и информации сохранено.
>>2696469На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков.
>>2696918>На вдвое уменьшенном прекрасно видна разницу. Ноздря, складка меж глаз, морщина на лбу, текстура кожи, лысина за линзой очков. Я вижу низкочастотные (те которые в левом верхнем углу на пикрелейтед) базисы дискретно косинусного преобразования, а не детали. Их убил задранный донельзя квантователь. А от даунскейла низкие частоты смещаются к более высоким, а высокие пропадают, так как их срезают для предотвращения алиасинга. В данном случае мы не видим потерю высоких при даунскейле, поскольку их и небыло в данном пережатке.
>>2698030>Tы слегка перепутал, jpg это то, что слева. Ну вот и говорит о том что с лева.С лева видно больше деталей.
>>2697986Ты математику свою вшивую в оценку сжатия не неси. А то уже целое поколение долбоёбов выросло, которые музыкальные кодеки по спектрограмме оценивают.Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.
>>2698130Свидетели деталей, что с вами не так?Если закодировать mp3 в 32 кбит/c, задрав срез lowpass фильтра на 20кГц, используя кодировщик, псиоакустическая модель которого позволяет сделать такое, ты получишь больше частот, ценой увеличения металлического звона и общего снижения качества, так как на те-же частоты выделяется меньше битрейта.В случае с ОП - пиком, там размер файла настолько мал, что на деталей бит не осталось, всё в квадратики ушло.>А давайте мы снизим разрешение и посмотрим на квадратики еще и интерполяции. В jpeg квадратики больше, значит и деталей больше.Так вы только снижаете разницу между кодеками>Ты математику свою вшивую в оценку сжатия не неси.Я может быть бы и молчал, если бы jpeg картинка не рассыпалась на эти самые базисы ДКП, и свидетели деталей тоже бы молчали.>Единственно корректная оценка методов сжатия - это визуальная оценка большинством живых людей.Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.Я вижу, то что у webp отображается как линии и контуры, то у jpeg превратилось в кашу из блоков. А ведь линии и контуры это тоже детали.
>>2698471Нет ноздри в твоём webp, пропала. Шакал без ноздри не шакал.>Кому то нравится пиксельное говно, кому-то зашакаленное, кому-то мыльное.Ну давай хоть MSE посчитай чтоле, идиота кусок.jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКА, неважно что кому нравиться, он использует объективную метрику, может неидеальную, но основанную на объективных свойствах человеческого восприятия.>Я вижу, то что у webp отображается как линии и контурыБелое пятно лучше квадратных глаз и носа?Без глаз и носа непонятно что это, человеческое лицо, или тупой фиолетовый двачер.
>>2692149WebP - замылил дорогу, замылил лес.Потерял цвета на дороге.Сделал логотип на строении слева ЧЕРНО-БЕЛЫМ.
>>2698589Ты можешь сколько угодно усираться что>jpeg основан НА МОДЕЛИ ВОСПРИЯТИЯ ЧЕЛОВЕКАно он всё равно не может закодировать линии в 3,6кБ.Здесь я специально обвел области на которых у webp линии более менее четкие в то время как у jpeg там каша из блоков
>>2698128>Канал связи с космосомеще ни разу не открывался>Закрывает третий глазкак будто он существует>блокирует чакрыи так заблокированы>Убивает богаубить можно только то что есть>выводит пришельцевто-то я в современной порнухе эти тентакли видел, это же инопланетные глисты
>>2703440Перед тем, как выкладывать результаты в пнг, удаляй метаданные о цвете в tweakpng. Или же следи, чтобы они были одинаковые у всех пикч.
>>2703440avif>webpДа, там деталей побольше, словно render distance выкрутили. Но облака мыльнее, да.avif vs heifКак это вообще сравнивать?Возникает ощущение, что кодировщик heic вместо тебя редактирует уровни. Вы уж там разберитесь с full->tv->full range преобразованиями.По детализации разница не большая, но heif кажется детальнее (это при том что avif сложнее кодировать). Может avif потом допилят по качеству. Пока они ускоряют декодеры.
>>2703440Вы сжимать webp не умеетеcwebp -size 46900 -z 9 -m 6 -f 100 '15764428295940.png' -o '15764428295940.webp'Размер: 43,6КБ>>2703440
Помогите объяснить необъяснимую хуйню. Я запостил в клиент вотсапа видео ролик, и если его проиграть - видно последний кадр. НО, если проиграть его в VLC или даже открыть в VirtualDub - этого кадра там нет! Это как блять?Ролик и два скрина - с ватсапа и VirtualDub - последние кадры. И они не совпадают.
>>2709158>libx264 slow 320k (6s)>libx265 slow 320k (55s)>libvpx-vp9 320k (3m)>libaom-av1 320k (6h 15m)Зачем так кодировать? Как можно сравнивать x264 закодированный за 6 секунд с av1, который кодировался 6 часов?Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.
>>2711339>Если уж и сравнивать, то на placebo, ну или в крайнем случае на veryslow.На таком битрейте будет одинаково хуевым.
>>2711629Достаем звук: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
>>2711633а какого-то гуи для этого вашего ффмпега не изобрели еще? чтоб не печатать 100 символов а сделать 5 кликов?
>>2686610 (OP)webp lossless как замена .png? Годнота! Практически во всех случаях webp получается меньше, а в среднем процентов на 20%. webp lossy как замена .jpg? Хуета! Нет, не так, webp lossy - в принципе хуита. Даже на 100% проёбывает непозволительное количество информации и совершенно отвратительно работает с градиентами. Так что в своей картинкпомойке перевел png в webp, а jpg различной степени сжатости пришлось оставить jpeg'ами разве что pingo'й прогнал.
>>2711750Соглы.Разве что heif сейчас вполне доступен стараниями эпола. Для лосси он уже однозначно обходит жопег.
В интернете встречаются картинки порой огромных размеров, таких как 7000х7000, которые очень долго декодируются на Core2duo.Были перспективы за вейвлетными форматами, что например для отображения эскиза будет декодироваться маленькая часть файла, вместо декодирования всей картинки целиком, что не нужно будет создавать эскизные копии одного и того-же, что для отображения на экране 1024x768 будут декодироваться только часть картинки до 875х875, а не вся картинка целиком и декодироваться оно будет быстрее. Но что-то не влетело. Вместо этого появился jpeg2000, который опять разбивает картинку на блоки размеров в степени двойки, который долго кодируется и долго декодируется.И вот на свет выходит FLIF, который хвастается своей прогрессивной загрузкой, которая суть всё тот-же ебаный интерлейсинг, который был ещё в гифках и png. Хочешь наделать эскизов? Декодируй картинку полностью нагружая CPU и забивая оперативку до свопа.
>>2712647Современные кодеки ставят целью максимальное сжатие, а тобою описанное — залупа в колёсах. Тем более, сейчас в любом шаёми 8 вёдер и 4+ гб озу.
>>2712647просматривал свой пак картинок. Оказалось что aritmetic jpeg тормозит сильнее чем webp. Причём aritmetic jpeg тормозит на картинках если размер больше чем 1000х1000, а webp если больше чем 2500х2500. И еще мне показалось что lossless webp меньше лагает чем lossy webp
Да походу av1 будет как и vp9 только в ютубе пользоваться таким темпами.А hevc уже захватывает сердца.
>>2713112Так имплементаций пока нет, и ускорение тонет. Если начнёт жать хотя бы 0,5 fps, тогда и появятся рипы.Хевку тоже не один год понадобился.
>>2713112Так а чё ты хочешь? >libx265 slow 320k (55s)>libvpx-vp9 320k (3m)Ты думаешь кто-то будет ждать кодека, который загружает 4 потока по дефолту, в то время как x265 загружает их все, как это было еще с x264. Да и знающему x264 проще освоить x265 чем libvpx-vp9.
>>2713352Я, к слову, о кодеке, потому что только их VP и ублюдочный WebP Lossy так хуёво работает с градиентами.
>>2713352Ну а чего вы хотели от 8-битного lossy кодека?Начнем с того что 8 бит на канал недостаточно для отображения всех различимых оттенков даже человеческим глазом. Для сглаживания градиентов применяют костыль, который называется дизеринг. Дизеринг это подмешивание шума с минимально возможной для данной разрядности амплитудой, который создает субъективное ощущение большей разрядности.Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.
>>2713635>Lossy кодеки ориентируются на сохранение деталей с большой амплитудой. ВЧ с малой амплитудой отбрасываются квантователем, то есть этот ваш дизеринг идет по пизде.В этом и пиздец. Кто в 2020 устраняет избыточность путём выпиливания ВЧ?
>>2714125>jpeg живее всех живых>практически все видеокодеки все еще занимаются DCT преобразованием, устраняют избыточность путём выпиливания ВЧ и блочат при нехватке битрейта>адекватной замены гифкам нет до сих пор>что-то спрашивать про 2020-й год
так то фотокамеры шумят достаточно сильно что-бы при сохранении в jpeg не заморачиватся с дизерингом.А вот для рендеров и фотошопов нужен формат с разрядностью побольше.
>>2714826> 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)
>>2714826For 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.
>>2714948>для воспроизведения этого говнокодека нужен суперкопьютер.>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.6x240p>frame= 9404 fps=111 q=-0.0 Lsize=N/A time=00:05:13.78 bitrate=N/A speed=3.72x360p>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.31xffplay отказался воспроизводить 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
>>2715766Лол 480р уже тормозит, а что там с 1080р или 4к? Даже на i7 будет тормозить. Пусть гугл себе в одно место засунет этот тормозной говнокодек.
>>2715781Видишь разницу между форматом видеокодека 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
>>2715794>ничего не тормозит>-threads 4Достаточного одного ядра для воспроизведения vp9 4к, а для av1 нужно 4? Хочешь сказать, что это не говнокодек?
>>2715842Довольно логично, что для воспроизведения кодека из 2018 не годится камень десятилетней давности.
>>2716008Ага, новый, требовательный к железу кодек для них как бальзам на душу. Уже предчувствую батхерт васянов с коре дуо, когда его начнут вводить повсеместно. Чому видево про танки логает??
>>2716033>начнут вводить повсеместноПираты пользуется тем, что удобно для народа, а на остальное насрать.
>>2716074Действительно, с чего это неуловимого джо должны волновать проблемы 90% оставшегося население
>>2716069>Ютубу так выгодно экономить на хранилище что кроме h264 + aac версий он еще кодирует и хранит vp9 версии и параллельно еще кодирует av1 для тестов.
>>2715794[libdav1d @ 0000016076c4a840] libdav1d 82eda83Stream mapping: Stream #0:0 -> #0:0 (av1 (libdav1d) -> wrapped_avframe (native))Press [q] to stop, [?] for helpOutput #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_avframeframe= 3604 fps= 49 q=-0.0 Lsize=N/A time=00:02:24.16 bitrate=N/A speed=1.97xvideo:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknownbench: utime=255.938s stime=8.812s rtime=73.274sbench: maxrss=418548kBХуй знает вообще, в чём проблемы. 4к и ноутбучная затычка вместо проца.
>>2713359Кстати да, VP9 на ютубе ублюдошно с темной частью градиентов работает, артефачит ее на каадраты. Я правда не могу быть уверен, что контентмейкер загрузил не уже в таком качестве
>>27136358 бит на канал кстати с дитхерингом просто прекрасно выглядит, даже повышение до 10 бит на канал ничего не дает визуально. Тут видать YUV 8 бит, а не RGB 8 бит потому что
2716118Не знаю, какую разницу ты увидел между yuv444p и rgb.Но вот yuv420p снижает разрешение цветовых в 2 раза по высоте и ширине, а потому сетчатый узор на цветовых каналах в yuv420p будет заметнее чем просто в RGB.>даже повышение до 10 бит на канал ничего не даетУ тебя 10 битный монитор и сигнал с видеокарты? Если нет, то в лучшем случае ты увидишь дизеринг.
>>2716128> Не знаю, какую разницу ты увидел между yuv444p и rgb.Ну я не знаю на счет именно yuv444 - таких видосов раз-два и обчелся. > У тебя 10 битный монитор и сигнал с видеокарты? Да, и я с лупой проверял тестовый 10-битный пнг в мадвр. 8 бит с дитхерингом неотличимо от 10 бит с дитхерингом. Без дитхеринга да, легко отличимо.
>>2716727Современные кодеки и низкий битрейт: av1 - 20кб/с — видео и opus - 11кб/с — аудио. Ну и 16 часов кодирования.
Как же хочеца HEIC, хоспаде. Поигрался сейчас с HEIC через https://convertio.co/fr/ (Потому что мой Xn-Convert стабильно выплёвывает ошибку)Оче круто.Качественные изображения (пикрил 1) переводит практически без видимых потерь со значительным снижением веса.Мусорные изображения (пикрил 3) также аккуратно переводит, но вес уже теряется просто пиздец как. Оцениваю с точки зрения мемасной файлопомойки. так что требования небольшие - чтобы изображение на глаз осталось такое же, с градиентами (привет Webp Lossy) и цветами. Тут всё норм, различия ищу уткнувшись в экран, когда как с Webp всё было практически сразу видно - меня устраивает.Из явных косяков - на одном из сложных JPG заметил, что он из ровных линий, делает квадратные (как будто понижение разрешения рендеринга в какой-нибудь игре), но были бы доступны крутилочки-вертелочки, думаю, можно было бы подобрать универсальный профиль.Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMP, а хочется повсеместного внедрения, чтобы и на телефон скинуть и на сайт.Еще бы AV1 пощупать...
Сап, сжимач, возникла такая ситуация. Имеется жёсткий диск, который заполнен лоли хентаем уже чуть менее чем полностью файлами всевозможных типов и форматов. Реквестирую как лучше всего имеющееся файлы перекодировать и сжать для минимального размера при сохранении качества или его минимальных потерях.И что почитать чтобы разобраться в этой теме?
>>2717980> при сохранении качества или его минимальных потерях.Thishttps://css-ig.net/pingoНастройки варьируются - lossless/небольшие потери/квадраты.
>>2717984Но это ведь только для фото. А у меня кроме их там и видео, и аудио, и текст, и даже несколько программ в портативных изданиях.Алсо я не против перековырять всё вручную. Софт из оп поста пойдёт под любые медиаформаты? Как кодировать?
>>2717995> Софт из оп поста пойдёт под любые медиаформаты?Да.Видео кодируй с такими параметрами: -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
>>2717971> чтобы и на телефон скинутьУ меня обратная задача - как смотреть с телефона в старой версии АЦДЦее (которая еще не полным калом была) никак
>>2717995>>2717980Медиа не сжимай, только текст, бинарники и подобное. Медиа и так в сжатом виде хранится, перекодируя не имея исходников ты просто получишь шакалов или ещё больший файл, в случае lossless. Всякие универсальные lossless алгоритмы, вроде lzma2, или даже жестокие алгоритмы семейства paq, поверх уже сжатых кодеками файлов дадут тебе парочку процентов.
>>2717971Ну, фиг знает.По порядку:png (6,43 МБ) -> heif (2,10 МБ) -> jpg (1,20 МБ).Heif сохранял гимпом без потери качества.Jpg c максимальным -quality 0 в ImageMagick.
>>2718248По качество/размер jpg, очевидно, сосет.heif (313 КБ) -> jpg (318 КБ).Оба с 50% качеством сконвертированы.
>>2718248Про размер согласен. Кажется тот онлайн конвертер что-то мудрит. Позже пробовал переводить JPG в WebP и он каким-то образом выдавал результаты, которые были всегда меньше оригинала и при этом обработаны явно с помощью WebP Lossless, потому что характерных артефактов на градиентах не было. При этом, когда я пробовал сжать эти же изображения с помощью нативной библиотеки cwebp результаты в WebP lossless всегда были в полтора-два раза больше, а схожий вес получался только с помощью WebP lossy, где всплывали видимые сразу же видимые артефакты. Другими словами, как конвертер тот сайт очень хорош, но не объективен.Еще, заметил, я думал, что это у меня из-за разницы вывода в гимпе и обычном картинкоменеджере - HEIC зеленит изображение, что довольно неприятно.
>>2718261>HEIC зеленит изображение, что довольно неприятно.Кстати, да. Гимп зеленит на выводе.ImageMagick и gimp в png.
>>2686610 (OP)>джипег как образчик сжатия на 10 из 10 по шкале ебучих шакалов>ко-ко-ко-ко-пок-пок-порЭЭЭЭЭк унижаем пээнгэблидей!!!А?
Какой положняк по кодекам и софту?av1 > h265 > vp9 > h264opus > vorbis > aac > mp3heif > webp > jp2 > jpgffmpeg для видео и аудио.convert из ImageMagick для изображений, но heif только чтение.
>>2718283>Какие исходники?RAW, нетронутые кодеком данные с камеры или микрофона.>>2718309>>2718028Порча информации.
>>2718278А, ну, если это чисто проблема GIMP'a, тогда формат хороший - одобряю. Тогда положняк - WebP Lossless - замена PNG.HEIC/HEIF - замена JPG. Ждём AV1
>>2686650> когда сделают на фчане, абу запилит сюда через неделю-две. с вебмами так же былоНа форчане до сих пор нет VP9 лол.
>>2718332aac строго лучше vorbis, vorbis имхо даже хуже mp3, но я накину ему за открытосьjp2 - маргинальщина, которой никогда не былоjpg и webp - примерно одного уровня, вопрос уровня "мыло или кубики", кому какие артефакты больше нравятсяavif очень потанцевальный формат, но в него вообще никто не умеет>convert из ImageMagickГовнокомбайн. Только специализированные енкодеры и оптимизаторы.
>>2717971>Проблема лишь в том, что единственная программа, которая захотела его открыть это GIMPNomacs через костыли поддерживает, макос/шин10 умеет, последние мобилки в хейф по умолчания снимают.Осталось только браузеры научить.
>>2718394>ГовнокомбайнУдобно через консольку работать с нужными кодеками изображений. FFmpeg у тебя тоже говнокомбайн получается.>>2718437>шин10 умеетТам пздц, конечно.В мсторе hevc/heic платный, а бесплатная версия только если железо поддерживает (мне повезло с этим). Открывается все это либо через стандартное "Фотографии" (или др софт из мстора), который мылит картинку. Либо через тормозные костыли в каком-нибудь xnviewmp открывать.Самая большая проблема в низкой распространенности новых форматов в приложениях и закрытом коде.
Можете нормально пояснить несведующему анону про все эти ваши форматы и кодировки? Я сейчас вижу эту картину примерно так:ФотоJPEG - качество средней паршивости, при сжатии шакалитсяPNG - лучше чем предыдущий, но и места отжирает большеWEBP - тот же джейпег, но меньше по размеру и сжимаясь размываетсяHEIF - НЁХ, скорее всего замена пнгВидеоТут нихуя непонятно, но webm>>mp4КодекиВ этом тёмном лесу нихуя не ясно. АудиоMP3 - для лоховOPUS - выбор мастеров
>>2718555> Фото> JPEG - качество средней паршивости, при сжатии шакалитсяСамое худшее качество> PNG - лучше чем предыдущий, но и места отжирает большеИдеальное качество, места естессно зрет стоко, скоко надо> WEBP - тот же джейпег, но меньше по размеру и сжимаясь размывается> HEIF - НЁХ, скорее всего замена пнгЗамена джейпегу, но бровзерами не поддерживается, так что на самом деле не замена> Видео> Тут нихуя непонятно, но webm>>mp4Это контейнеры, а не алгоритмы сжатия> Кодеки> В этом тёмном лесу нихуя не ясно. > Аудио> MP3 - для лохов> OPUS - выбор мастеров Всё так
>>2718560А видео примерно так, от плохого к хорошему:MJPEG (в PS1 юзалось)MPEG2DivXH.264/VC1HEVC/VP9AV1
>>2718560Стоит отметить, что у 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) и итоговые ключи выдавали самую качественную картинку на мой взгляд. В целом получается +- оригинальное качество, но намного меньший вес. Из минусов - большее время перекодировки, но не особо заметно на изображениях до двух мегабайт.Дополнения приветсвуются.
>>2718576> перевода картинокомойки_jpg в картинкопомойку_webpдважды пережимать с потерями? во сколько раз выигрыш в весе не написал даже.
>>2718560>webp>но бровзерами не поддерживаетсяЧто значит не поддерживается?https://caniuse.com/#feat=webpНичего что не поддерживают только ишак и сафари. А про KaiOS Browser кто нибудь вообще слышал?
>>2718633Да, это я что-то на радостях написал от того, что удалось избавится от ужасных градиентов, но всё равно достаточно много деталей мылится, с 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 кб
>>2718772При этом довольно интересный эффект наблюдатся - на маленьких зашакаленных jpg webp наоборот делает лучше, убирая своим мылом мусорные квадраты png. собсна первые два пика релейтед.
>>2718772> Конвертировать всю файлопомойку я не стал, подожду AVIF или HEIC. через 10 лет еще что-то запилят, будешь третий раз её сжимать
>>2718571У пнг, имей ввиду, размер зависит от проги, сохраняющей его. В фотошопке самым маленьким получается
>>2718698Не-не, я это знаю, я токо про хеик писал, вебп предыдущей строкой при копировании просто осталось
>>2720254FLAC - пожатие аудио без потерь (lossless). Избыточен для 99% слушателей и только для отбитых аудиофилов.MKV - контейнер, куда удобно запихать кучу дорожек аудио/субтитров. Развит в webm.
Вы знаете, что miro-video-converter (https://github.com/pculture/mirovideoconverter3) очень круто сжимает!? И ещё вопрос, что это за порода собак?
>>2720380Когда кажется, нужно снизить дозу, если бы ты знал породу, то и не стал отвечать вопросом на ответ...
>>2720377>шкурка для ффмпег>очень круто сжимает>последний коммит 7 лет назадУникальный софт, достоин уровня /s.
А вообще самый крутой формат сжатия музла - трекерный лол. Типа .mod, .it, .xm, .s3m. Вот этот трек например в оригинале меньше 400 килобайт весит. Но есть нюанс...
Что там по ОПУСУ кстати слышно? Никаких обнов с апреля прошлого года. Всё, кодек уже допилили до идеала, ничего фиксить не надо?
>>2720400В трекерных очень всегда сухое звучание, без сложных ревербаций, мне не нравится, скушно такое слушать
>>2720409Ну возьми "мокрые" семплы, в чем сложность? А ведь прикольная идея - кодировать исходный файл не сжатием, а реально конструированием и программированием, раскладывая его на семплы и скриптуя. Чтобы не человек в трекере сразу семплы набивал, а прога из стомегабайтной вавки сделала .mod на 300кб, неотличимый по звучанию от оригинала. Но для похожей хуйни наверно такие вычислительные мощности понадобятся, буквально суперкомп с ИИ. И один файл будет кодироваться сутки.
>>2720512>если нужно кодировать потомЭто студийный юскейс. Флак в бытовом прослушивании никому не всрался.
>>2720464В гну/линуксе почти на всё есть мокрописька на гтк, мокрописька на кьюте и мокрописька на нкурсес.
>>2721593Я сейчас выбираю для скачивания mp3. Потому что по дефолту сейчас везде стриминг пашет. А в нестандартных местах у mp3 выше всего шансы быть проигранными.
>>2721678Долго расшифровывал твой пост, а потом понял что ты просто зумерок со стримингом вместо hdd. Так зачем тебе вообще выбирать аудиокодек из раздач торрента?
>>2722368> вектор, а также векторные анимации это топТолько вот приличных форматов векторной анимации нет со времён почившего флеша.
>>2722245>стримингом вместо hddКак что-то плохое. Цивилизация даёт блага - пользуйся. Нет хотим газку поддавать.
>>2723110>Что значит получается? Всегда им был и остается.А вот тут ты обосрался. Он модульный, перед компиляцией можно выбрать нужный функционал и исключить лишнее.
>>2724803Зачем, когда обычный ASCII файл открывается практически на любой системе очень большим количеством программ.
>>2724820Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.>>2724813Там все очень плохо.
>>2724824>Хочется сферического пожатия в вакууме. Экономия места и с нынешними мощностями мгновенно все будет с каким-нибудь открытым методом с хорошими место/скорость показателями. Ясен пень не паком, эти 22Мб 17мин жались.Запили раздел на бтрфс со сжатием zstd.
Можно в ffmpeg как-нибудь предсказать размер, исходя из параметров и соуса, видео до ожидания 100500 часов кодирования?
>>2731217зависит от формата, но в случае h264/h265 работает такая формула((bv + ba) * t) / 8192bv - битрейт видео (bps)ba - битрейт аудио (bps)t - продолжительность видео (s)
>>2731436Спасибо. Но битрейт видео какой вписывать, если он постоянно прыгает?А для vp9 есть что-нибудь подобное? Приходится с разными -crf в 3-4 потока одновременно запускать кодирование того же видео (все равно vp9 не полностью проц нагружает, как h264).Алсо, тут пробовал сравнить гпу кодирование с h264_nvenc и обычный h264, но получаются совершенно разные результаты с командами, отличающимися только этими кодеками.
>>2686610 (OP)Аноны, как сжимать аудио через libvorbis, чтобы конечный файл был без видеопотока? Сжимаю коммандой:ffmpeg -i 1.m4a -c:a libvorbis -q:a 0 1.oggно почему-то на телефоне открывается, как видео. Как исправить?
>>2686610 (OP)Не уверен, правильный ли тред, но ладно.Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее.
>>2731948>H265>i7 2600Ну ты пони. Во-первых, да, SSD может влиять. Во-вторых, 2700k, при всём уважении к Sandy Bridge, монтаж h.265 просто не тащит, как бы ни было горько это признавать.
>>2731983Жалко. Все-таки удивительно, что ноутбучный процессор 4/8 на 15 ватт справляется лучше, чем десктопный 4/8 большей частоты на 90 ватт.
>>2731996Ничего удивительного. У кукурузера, емнип, аппаратная поддержка декодирования h.265. Годы никого не щадят.
>>2723859а куда оригиналы делись? экспорт данных гугла выдаёт оригиналы, как минимум 8-летние оригиналы ещё целы
Стандарт AVIF вроде окончательно принят, а никакой софт до сих пор в него не умеет или я плохо искал? Особенно интересно насколько лучше lossless сжатие в сравнении с webp
>>2737331> софт до сих пор в него не умеетЭто. Только очень эпизодические звери.>lossless сжатиеВсе новые форматы фокусируются вокруг удаления избыточности. Нечё от них лослесс побед ждать. Юзай специализированный flif.
>>2737361А где же поддержка всеми мировыми корпорациями, где же попенсорс с гитхаб-бинарниками от васянов...>FLIFУ меня не взлетел, при конвертации полноэкранных пнг скриншотов во флиф файлы в основном были немного больше чем вебп лосслес. Последний к тому же быстрее открывается и имеет превьюшки в проводнике дриснятки. Для перегона юзал XnConvert, возможно там не те либы и можно получить результат получше
>>2737331>или я плохо искал?https://github.com/AOMediaCodec/av1-avif/wikiпока мало что, да и то не всегда нормально работает, можно еще руками через Aomenc сжимать и потом муксить MP4Box>Особенно интересно насколько лучше lossless сжатие в сравнении с webphttps://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 склеивается
>>2740170--zones в x264У ffmpeg можно квантование на лету менять, но я не помню как, слишком давно это было.
>>2740384>>2740170> У ffmpeg можно квантование на лету менятьВозможно вот это, но кажется другая команда была, это возможно старая команда, которую заменили.
>>2741186>с BPGBPG - мертворождён, можешь забыть про него.Вместо него, с лёгкой руки эппла, пришёл по сути тот же HEIF.И конечно же WebP проигрывает HEIF во многом. Во многом, кроме распространённости и поддержки в ПО.
>>2741191>BPG - мертворождёнТак-то WebP тоже. К тому времени когда его поддержку добавят везде и им даже начнут пользоваться люди он станет ненужен из-за ширины канала и возможностей железа юзать повсеместно PNG, а аппаратная поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000 делают жопег и вовсе неубиваемым в обозримом будущем, это говно не утонет, прост в настройках шакалирование будут меньше пользовать. WebP мертворождённое говно, в попытке "пожать" сделали говнище, которое в затратах процессорного времени соревнуется с полноценными lossles (и обгоняет их), при этом ещё и качества не даёт.
>>2731948>Монтирую видео (оригинал в H265) в премьере и превьюха в премьере жестко тормозит на i7 2600, что аж невозможно. В всмысле, на ноутбуке ryzen 3700u она меньше тормозит, хотя ноутбук очевидно слабее. Даже без учёта того, что у 3700u аппаратная поддержка H265 в видеоядре, он на клыка сэндику даёт. Там блядь оперативная память в два раза почти шустрее, инструкции новые и старый Гипертрединг времён Сэндика на фоне Скалейковского и Рузеновского гипертреда это говно.
>>2741201>К тому времени когда его поддержку добавят вездеОна сегодня и есть практически везде.>поддержка JPG с его производными типа JPEG XR, JPEG-LS и JPEG2000А вот у этих нет и никогда не появится. Вот и вся история.
>>2741219>Она сегодня и есть практически везде.1. Если бы работал в веб макакинге, то знал бы, что он практически нигде не используется.2. Я больше скажу, сам гугл в рот ебал свой WebP, используя исключительно SVG, PNG и JPG на своих сервисах, проще говоря, WebP не нужен даже Гулагу. Вот тебе пруф, можешь сам отинспектировать сервисы гугла, везде svg и png.3. А теперь самое смешное, основное применение WebP по состоянию на 2020 год это пережатие уже уебански шакальных jpg с сайтов для онлайн конвертации и отдаче юзеру через CDN.4. Apple Safari.
>>2741223> сам гугл в рот ебал свой WebPОн его для юзер-контента использует, превьюшки на ютубе, картинки/иконки в плейсторе
>>2741226>превьюшки на ютубеЛол, нет.>картинки/иконки в плейсторе Иконки - да. Часть картинки обложки, наложения кнопок плей и т.п. png.
>>2741227А в плейсторе он оказывается отдает хрому вебп, а лисе пнг. Хотя с тем что вебп нинужен я согласен.
>>2741205> Гипертрединг времён Сэндика на фоне СкалейковскогоА что изменилось? По сравнению с смт все такое же сендиговно.
Для avif теперь выкладывают билды под винду, плюс завезли поддержку png https://ci.appveyor.com/project/louquillio/libavif/build/artifacts
Анон в /a/ помню год назад скидывал Evangelion 1.11 влезающий в 40 Mb двача, и при этом это можно было даже смотреть, фильм на полтора часа. Есть у кого этот файл?
Что то странное происходит с 251-м opus на youtube.Как то раз, загрузил на youtube flac, он его тогда пережал в aac, ну ничего особенного от этого формата я и не ожидал. Потом я забыл про то видео и пережал для себя тот флак в opus vbr 144k.Теперь youtube кодирует vp9/opus версии. И на том видео тоже появилась opus версия. Ну думаю, ща посмотрю на спектры со всеми 20 килогерцами. Ага, щас! Ютуб их зачемто взял и порезал. Этот срез похож на mp3, но нехарактерный для opus. Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра.Главный вопрос: Зачем? Зачем они приравняли частотный диапазон к aac версии трека? Это они так пытаются продвигать свои сервисы "Youtube music" или "Google Play Music"?
А есть для опуса какие-нибудь костыли, которые анализируют mp3шный трек и исходя из его битрейта, частот и энтропии сами выбирают пресет для сжатия типа "чтоб примерно так же осталось"?
>>2749772> Те остатки которые видны на спектрограмме можно списать на недоработку lowpass фильтра. Нет, они похожи именно на мр3 стайл оставление только самых громких пиков свыше 16 КГц
>>2756376Хех, мда. А не лучше будет скачать желаемый музон в флак, а потом пережать в опус желаемого битрейта? Избежишь двойной потери качества
>>2756387Почему ты решил что это музыка, и что она существует в каком-то другом экземпляре? Двач ты не меняешься.Это архивные записи разговоров, при том в огромном количестве, из разных источников и с разным качеством.Я конечно могу засесть на две недели со слепым тестированием и подбором битрейта. Но хочется один такой ключик типа -mp3_like как тут >>2718772 который примерно оставит всё как есть, но позволит занимать меньше места.
>>2756296lowpass фильтры не идеальны, и при громких пиках они оставляют мусор в спектре они не полностью их подавляют, так что они остаются в спектре с приглушенной амплитудой.В принципе, их можно подавить средствами самого кодировщика, путем подбора квантователя для соответсвующей полосы частот так, что-бы этот мусор остался за порогом округления, но qaac почему-то этого не сделал.А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазон. А поскольку после lowpass фильтр не идеален и оставил после себя мусор, то opus взял и закодировал его как смог.Для примера 2-й пикрелейтед mp3 320kbps. Здесь видно что спектр отфильтрован, но оставшийся сигнал имеет примерно ту-же громкость мощность, энергия, как оно правильно называется?, что и сигнал с другой полосы частот. Это и отличает фильтр в mp3 от просто lowpass фильтра.А теперь снова посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3.
>>2756280>>2756354>пресет для сжатия типа "чтоб примерно так же осталось">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.
>>2756488> lowpass фильтры не идеальныЦифровые - идеальны)> А opus еще на 32-х килобитах в секунду пытается закодировать весь диапазонНу он даже на 144 кбит/с на ютубе режет под 20 КГц (по моим тестам в фирефох-треде) (притом полный диапазон - 24 КГц)> посмотри на ту спектрограмму ютубовского опуса. Там сигнал в самой высокочастотной полосе частот тише основного спектра, что является признаком применения именно lowpass фильтра перед кодированием, а не фильтрации высокобитрейтного mp3. Хотя да, но ослабление громкости слишком слабое
>>2686610 (OP)Хули толку. Большинство этих форматов здохнет, как и все технически более совершенные «убийцы» mp3, jpg, rar и т.д. Популярность и распространённость — вот что действительно важно.Всем этим 7zip-ам, опусам и прочему jpeg2000 вечно ютиться на задворках интернетов, поддерживаемые на искусственной вентиляции лёгких силами трёх с половиной задротов. Мне, разумеется, тоже не нравится эта ситуация, когда привычка стоит на пути прогресса, но хули делать.
>>2756561>Популярность и распространённость — вот что действительно важно.heif - дефолтный формат айфонов, поддерживается практически всеми ОС. Как только браузеры научатся - вот тебе и наступит новый жипег.
>>2756564HEVC не поддерживают принципиально. А HEIF, обертку под HEVC для картинок, значит поддержат?
>>2756559>притом полный диапазон - 24 КГцу него нет режима 44100кГц, поэтому он ресемплит до 48кГц.а срез 20кГц на всех битрейтах (за исключением самых низких) это у него по дефолту.>Цифровые - идеальныСмотря какой фильтр. Вот lowpass фильтр у Audacity там срез максимум 48 децибел на октаву. Приходится многократно повторять этот фильтр,что-бы действительно срезать ВЧ.
>>2756576В Аудишне FFT фильтр начисто срезает, если настроить соответствующе. И отдельный low-pass filter есть вроде бы
>>2762263А почему его должны часто обновлять? Тулсы вообще по несколько лет обновляются, tak вон с 2013 пилится, беты там какие-то. mpc с 2009, wavpack, flac раз в два-три года, это нормально, а народ продолжает массового поедать мертвый mp3, классика.>>2756576А если у меня исходник PCM в 44, то как быть? SOXом переводить исходник в PCM 48 и жать потом его в opus? или SOXом переводить уже готовый lossy opus 48 в 44, полученный из исходника PCM в 44? Opus вообще сможет в 44 кустарно c вышеописанным и есть ли в этом смысл/плюсы/минусы? Не понимаю в этом. Теряется ли качество из-за PCM 44 пережатый в opus 48, не считая естественной потери pcm->lossy, чисто за частоту дискретизации спрашиваю.
>>2762296> почему его должны часто обновлятьНу самый свежий из lossy вроде, только в 2012 формат запилили.
>>2762301Гуглить то хоть пробовал? Никуда не делся твой opus, развивается.https://git.xiph.org/?p=opus.githttps://git.xiph.org/?p=opus.git;a=log
>>2762296Ну в сам opusenc встроен ресемплер. Но если сомневаешься в его качестве, можешь и через sox перегнать.Передискретизация, с учетом неидевльности lowpass фильтров, может вносить дополнительные искажения. Только вот являются ли они существенными при lossy компрессии?По умалчанию opusdec такой сигнал снова отресемплит до 44100 Гц. А вот foobar2000 будет воспроизводить в 48 кГц без ресемплинга.Ещё учти что звуковуха может нативно не поддержитать 44100 Гц. Тогда ей всё равно понадобится ресемплер.
>>2762657> Ещё учти что звуковуха может нативно не поддержитать 44100 ГцВсе звуковухи реалтек передискретизируют всё аудио в 48 КГц, если в панели 48 стоит, насколько я понимаю.
>>2762961Во-первых лосслес в плане математики ультрапримитивен, там всё изобрели уже 30 лет назад. Чё его в 2к20 обсуждать?Во-вторых, в 2k20 основной потребитель контента - это мобилки, где размер хранилища определяется маркетингом а не техпроцессами. Да даже компы сейчас стараются укомплектовывать ссд, а данные выносить на насы. Так что сжатие в 2к20 - более чем актуальная тема.
>>2763227Я тебе про ситуацию в экосистеме, а ты мне ad hominem про одного человека. Давай вкатывайся в формальную логику, пока не поздно.
>>2763468На самом деле в 2017 году за 42К айфон имел 32 ГБ (и их не расширить MicroSD), а за 16К Сяоми - 64 ГБ, так что это айфоны обделены хранилищем
>>2763468Ни в один флагман не удастся всунуть десяток терайбат, как в старую добрую пеку. Потому с раземером в любом случае приходится считаться.
>>2762657Вижу ты хорошо шаришь. Не мог бы пояснить еще пару моментов с PCM? С такими вопросами ньюфажин аудиофилы сразу гонят тряпками.1) Достаточно ли ужимать 24-битные PCM в 16-битный PCM с обычным дизерингом фубара или нужны обязательно всякие нойзшепинги дополнительно для такого?2) При конвертировании PCM Aiff в PCM Wav идентичной битности теряется ли качество? И тоже нужны ли в таких случаях конвертирования всякие дизеринги и тд/тп?
>>2766418Я неон, но по 1) скажу, что твоя пекарня издает такой шум, что динамического диапазона 96 дБ даже с дитхерингом без нойз шейпинга выше крыши будет, ты весь этот диапазон не услышишь в условиях существенного фонового шума.
>>2766464Только непонятно, зачем ужимать, у тебя звуковуха только вывод 16 бит что ли поддерживает? 24 нет?
>>2686610 (OP)Но WebP на четвертой объективно хуже. У него же даже морщины разгладились, неужели ты этого не видишь? Типичная ошибка новичка в шакалинге - мыло вместо частичного сохранения деталей.
>>2766466Да просто экономия места, музыки пиздец уже, в облако кидаю не часто прослушиваемые жанры. У меня интернет еще не особо то быстрый, выкачивать потом эти 24, я смысла в них особого не вижу, мне мастерингом не заниматься, бутлегов писать не планирую. А если нужно побаловаться, то всегда можно достать их из первоисточника, в данном случае Bandcamp.https://bandcamp.com/fossf1/following/genreshttps://bandcamp.com/fossf1/following/artists_and_labelsТы просто глянь на списочек жанров, устанешь, а я всё это чекаю, покупаю, качаю, слежу.Поясни за второй вопрос, вброшу что-нибудь
>>2766567А по второму вопросу - я забыл, что за aiff, в чем его особенности. Ну если идентичной битности, то какие могут быть потери? Наверное никаких
>>2766565>частичного сохранения деталейЭто не частичное сохраненение деталей. Это имитация деталей артефактами сжатия.Не скажу, что это плохо, кстати.
>>2766593Да это тот же PCM, только эппловский. Блин, раздражает немного что не все кодировщики его поддерживают и в таком случае сначала aif/aiff в wav жать приходится.Так уж и быть, раздаю бесплатные подарки. Спасибо за инфу. https://www60.zippyshare.com/v/IHyIka4F/file.html
>>2766649> Да это тот же PCM, только эппловскийALAC жи есть, я как раз его юзаю, чтобы на афоню скинуть лосслесс музон в Apple Music. Эпловский аналог FLAC. Конвертирую в него из FLAC.
>>2766652Да я в данном случае предпочитаю Wavpack, в нем есть неоспоримая фича когда нужна экономия места. Гибридный режим позволяет держать сразу lossless и lossy размером как любой другой lossless контейнер. То бишь возьмем твой трек ALAC, предположим размером 25мб и Wavpack тем же 25мб, в которые ужались сразу lossy и lossless и их общий размер составляет тот же 25мб. А в случае ALAC получится что к этим 25мб нужно еще прибавить ~10 для хранения lossy AAC, получится уже ~35. Я знаю что на FLAC тоже есть такое, но сторонними васянами написано и не уверен будет ли работать везде, уже жаловался народ на траблы. А в Wavpack это из коробки.>>2766655Что-то с кодировкой не то, перекодируй документ, если нужно, да там ничего важного не написано, просто комментарии для упрощения. Но хоть официально бесплатное и в любом формате.
Как научиться пользоваться архиваторами?вот например есть файлы, которые когда-нибудь (возможно) понадобятся, но большую часть времени они только валяются на диске. Как их лучше всего упаковывать и сжимать?Попробовал случайным образом потыкать пресеты 7-Zip, но ничего путного не получилось, а в некоторых случаях архив даже начал больше весить, чем исходные файлы.Каким образом добиваются уменьшение размера в два раза и выше? Например как в репаках игр или здесь: https://rutracker.org/forum/viewtopic.php?t=5489805
>>2767650Создаешь профиль по умолчанию в винрар с форматом архива Rar с максимальным сжатием, и если по одному не будешь файлы вытаскивать, то непрерывный архив
>>2767728>FFmpeg>пикабушник>Православная это GUI для FFmpegсовсем дебич? Пошел обратно на свой пикабу и больше не возращайся.
>>2777882cwebp -z 9 -lossless -mt (без потерь)cwebp -m 6 -z 9 -near_lossless 80 -mt (без визуальных потерь, чем меньше число -near_lossless, тем меньше результат, но больше потерь)Если просто для хранения, то можно и BMFhttps://www.compression.ru/ds/bmf_2_01.rarСам формат это не какой то стандарт, но это один из лучших сжимальщиков без потерь, сразу он PNG не понимает, надо предварительно сконвертировать например в PPM:ffmpeg -i image.png image.ppmУже потом сжимать:BMF.exe -s -O"image.bmf" "image.ppm"
>>2777882>>2777961>>2777999>>2777887Потестил.Везде максимальное сжатие без потерь, кроме heic. В нем есть минимальные отклонения. Был бы вином, если бы не зеленил картинку, и нет нормальных приложений для просмотра.JPC - LuraWave JPEG-2000 Format, без потерь и быстро, но мертвый.AVIF - oche dolgo, даже в webp будет все конвертироваться ~30 часов.
>>2778105Тут только нужно смотреть как конвертируется в AVIF и HEIC, скорее всего в yuv444/yuv422 (а это уже потери, как при цветовом преобразовании, так и сохраняется меньше самих цветов).В AVIF настоящий lossless режим есть через https://github.com/AOMediaCodec/libavifAvifenc --losslessДля HEIC были какие то форки с RGB, но надо разбираться и размеры там будут существенно выше.У Webp если недостаточно скорости, можно использовать настройки побыстрее, даже на них результаты вполне себе.
>>2778105Можно еще посмотреть тесты, которые я кидал в другом треде https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/Также там есть тест PNG оптимизаторов (в табе PNG), в Jpeg XL сжимать на максимальных настройках тоже будет очень медленно, да и сам формат пока еще развивается, вроде как уже стандартизировали, но есть вероятность что новые версии не распакуют старые пикчи, тут уж на свой риск.
>>2778294Он также в них сохраняет дополнительные данные для обратного преобразования без потерь в 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" с этой пикчей >>2687799, но результат весит больше, чем лосслесс вебп.
>>2778567Так и жать, если нужен настоящий 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)
>>2763470Кек, а в ноклу 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 в нижнем правом углу и засунуть его в финальный шебм. И всё это сразу одной строкой в консолечке. Чот получится наверно пердолинг не хуже установки генту.
нихуя не понимаю, нахуя рекомендовать heic / avif?Была папка 7гб, и bmp, и jpg, и png, разные размеры, разное качество, с прозрачностями и без, анимации и без.Прогнал за 5+ минут с помощью xnview в webp, в результате и проводник читает формат, и папочка сжалась до 1.4гб, и в программах фоточки видны.Попробовал перегнать сначала те же 7гб в avif / heic (результаты одинаковы), 4% (я хз сколько это мб, может мб 300-350), около часа.Впизду я ебал такой пиздец. Вы ебанутые.Ради теста взял AVIF / HEIC / WEBP посмотрел на то, что получилось, и время затраченное.всё кроме webp не выдерживает никакой блядь критики.Как по поддержке банально софтом, так и по времени обработки, конвертации, сжатия, и так далее.Вопрос - нахуя он нужен?
Прошу прощёния если уже было.Хватаем первую попавшуюся в папке гифку (пнг и джипег пока не вкостылены) и приклеиваем звук.
>>2778978Отступы там - самый из незначительных грехов. Он нигде не определяет рабочую папку, потому если запустить скрипт типа ~/scripts/myyobaffmpegwrapper/yoba.sh, то они пидорнёт случайный трек и картинку с хомяка.
>>2778945Лучше сначала просто перегнать гифку в видео, а после объединить с музычкой:ffmpeg -i audio.mp3 -stream_loop -1 -i video.webm -c:a libopus -b:a 64k -c:v copy -shortest output.webm
>>2778913>9900kНе, у меня не 9900k конечно же.Но i5, довольно производительный.Поэтому я хз, это нихуя не норма.
Записываю окно с ffmpeg -f framerate 60 -i -title "window_name" -c:v h264_nvenc -qp 0 output.mkv. Курсор двигается, но окно заморожено. Если с такими же параметрами записывать весь экран, то все норм. Чяднт?
>>2778865>>2779871> HEICЛол, ты чем жал? Я через ffmpeg + паковщик (gac) минимум по 10% получал, даже с суперужатых пикч с вк. Если ты не в состоянии понять как оно работает, это не значит, что оно не работает. Не завезли ещё поддержку, гружу сюда.https://files.catbox.moe/znx8on.heicВот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижу inb4: слепой.Кодировалось это всё на slow 4 секунды. На placebo 15.Делюсь скриптом для красноглазых: https://pastebin.com/9pwb2kNbА avif говно, тут согласен. Полчаса одну картинку обрабатывает.
Котаны, возможен ли в принципе горизонтальный флип (т.е. зеркальное отображение) видео без пережатия? Ну или как и чем это сделать с минимальными потерями?
>>2780419Метадатой дописать hflip, например?https://it-handbook.ru/windows/povorot-mp4-video-s-pomoshhyu-ffmpeg.html
>>2780444А, сорь, только сейчас посмотрел что не то кинул.Вот тут чувак флипает метадатой и судя по всему мало какие плееры проигрываю его хотелки: https://superuser.com/questions/1393880/edit-mp4-hex-data-to-vertically-or-horizontally-flip-video-in-a-lossless-manner
>>2780365>минимум по 10% получал, даже с суперужатых пикч с вкТолько такая конвертация не имеет смысла, выигрывается мало, а потери при повторном будут всегда, даже в такой же или чуть больший размер>Вот у меня мужик с котом есть. 3 метра превратились в 560кб, разницы я не вижуРазницу видно, в основном сожрало все детали, но это ладно, бывает что нужна просто фотка поменьше без сильных артефактовНо если такие потери устраивают, вот для примера WebP даже чуть меньшего размера чем этот HEIC https://files.catbox.moe/uukfg3.webp (с ним тоже скорей всего разницы не будет видно, а учитывая что у HEIC никогда не будет поддержки в популярных браузерах из-за своих жестких патентов, то смысл все в него все переводить)
Жму аудиокниги и подкасты в opus VBR 56 (ниже уже явное говно и если в книге есть музычка, то лают шакалы). Жал лёгкий тихий джаз для прикола в CBR 64 - охуел от того, что на слух сложно отличить от исходника. Более насыщенная и громкая музыка типа митола естественно рассыпается в говно даже на 128. Всю коллекцию музла из mp3 320 и флака перегнал в ogg vorbis 192, остался доволен.Всё правильно делаю?Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете? Пытался найти баланс в жпг, на 75 шакалы вроде не так ужасны, но выигрыш по качеству маленький.
>>2780855> начал с опуса, закончил ворбисом> пережал из лосси mp3 в лосси ворбис> Всё правильно делаю?Ну как сказать. Я согласен, что 192 опуса с ютуба находиться на одном уроне с 320 мр3, но пережимать лосси в лосии - такая себе затея. Потери накапливаются. Твоё право, если ты разницы не слышишь. Главное это своё говно пережатое потом среди других не распространяй.> Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг.Начни с webp. Незначительно проигрывает heif, зато быстр и поддерживается уже практически всеми тостерами.
>>2780855Алсо если реально ЧБ а не оттенки серого, то можно много выиграть путём принудительной индексации и пнг-оптимизации. Но тут смотреть реальные примеры надо.
>>2780869>пережал из лосси mp3 в лосси ворбис320 мп3 это очень хорошее качество, которое от лосслеса хуй кто отличит в принципе. Ну может пара миллионов уникумов на всей планете с феноменальным слухом что-то будут подозревать. Пережимал чтобы место освободить (сотни гигов).>такая себе затея. Потери накапливаются.В курсе.>Твоё право, если ты разницы не слышишь.Либо не слышу, либо отказываюсь верить, что есть какая-то разница. Музыкант+звукач, зарабатываю этим деньги, со слухом всё ок, всё ещё могу слышать 19500Гц, хотя уже бородат.> Главное это своё говно пережатое потом среди других не распространяй.Не понял этого. Зачем я буду свою личную коллекцию музла где-то распространять?>Начни с webpПопробую.>heifXnConvert почему-то ошибку выдаёт, "файл не является изображением". Через что ещё попробовать?>>2780875Попробую, спасибо.>>2780876Слишком толсто. Сосите хуй, пожалуйста.
>>2780855>Теперь ищу способ уменьшить размер коллекции манги, в основном ЧБ, смесь жпг и пнг. Что посоветуете?Если не так срочно нужна поддержка везде, то можно подождать Jpeg XL, у него очень хорошее lossless сжатие (для перегона пикч с PNG, иногда чуть хуже FLIF, но вот только FLIF существенно медленней, на декодирование даже в десятки раз и он заброшен) и плюс к этому можно уменьшить обычные Jpeg на 20-23% совсем без потерь (пример в онлайне https://google.github.io/brunsli/), ну а с потерями и еще больше.В другие форматы уже такое себе, ну разве что еще в WebP есть вариант PNG пережать без потерь (все остальное или плохо жмет в lossless или очень медленно), а вот Jpegи пусть лежат, они все таки обычно поменьше PNG весят, да и каждый раз дополнительные потери будут (выйдет еще какой то новый формат и опять захочется пережимать, еще больше все зашакаливая, ну или искать все эти исходники)
>>2780869>начал с опуса, закончил ворбисомОзадачил ты меня этой фразой, решил проверить. Взял исходник в wav, пережал в vorbis 192 и opus 128, чтобы их размеры были примерно одинаковые. Закинул все 3 в давку и начал сравнивать, пуская в противофазу, ну и хули, как и ожидал - vorbis срезает ультра-высокие как обычно, в противофазе слышно исключительно шипящие, а opus вырезает вообще по всему спектру по чуть-чуть и в противофазе с wav слышно разницу вплоть до суб-низов, но высокочастотное шипение и на vorbis и на opus примерно одинаковое. Вот хуй знает, что из этого лучше - чуть больший срез высоких у vorbis с сохранением всего остального или вырезание по всему спектру у opus.
>>2781371Ну так. Огг - это всего лишь контейнер. А ворбис и опус - совершенно разные кодеки из разных эпох с разными задачами.Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа. Плюс апконвертит в 48000, потому лучше на родной частоте и сравнивать.Ну и чисто моё мнение. Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой Lowpass "режьте всех кто выше 18к, господь разберётся где свои".
>>2781429>с разными задачамиНу вот поэтому я и пережал всю музыку в vorbis 192, а аудиокниги в opus 56 VBR, потому что opus реально круто себя ведёт на таких низких битрейтах и голос в книгах не превращается в глухое бульканье как с другими кодеками.>Опус, емпнип, добавляет смещение. Сдвигай фазу для минимизации диффа.Вот про это не знал. Попробую.>Лучше когда акустическая модель вырезает инфу везде понемногу, чем тупой LowpassСкорее вопрос вкуса, да и для разной музыки разный подход скорее нужен. Наверное если прогнать пару десятков очень разных жанров через спек, то обнаружится, что в половине из них информация выше 16-17КГц вообще отсутствует.
Запарился, короче, вопросом перешакаливания жипега в хеиф. Нашкалил жипегов от q100 до q4, затем каждый пожал хейфом от 100 до 1 и поссчитал ssim по отношению к несжатому оригналу. Ну вот какие выводы просятся:1) Хейф расшакалваиет пережатый жипег - подтверждено. Конечно только сильно пережатый с q<60 и на определённых настройках, и не больше чем на пару пунктов, но байки "хейф сделал файл лудше" теперь не такие байки.2) Практически всегда можно не ссать и переживать до heif q80-60 , качество скорее всего останется неизменным, в худшем случае снизится до жипега уровня q95.3) Нет нужды запариваться и искать первоисточник. Как бы исходник изначально не был пережат - его искажения предсказуемые: либо не хуже чем напортило в жипеге , либо потом перходят в кривую пережатя оригинала.Пока только глаз, сейчас ещё фотки с другой энтропией попробую.
>>2780365>А avif говно, тут согласен. Полчаса одну картинку обрабатывает.Так нехуй выкручивать speed на ноль. Оставляй дефолтное значение, можно ещё jobs выставить по количеству потоков проца.
Обнаружил что у меня была старая версия опуса в гуй-мокропиське. Скачал последнюю, воткнул, заебись. Аудиокниги в 28 VBR охуительно кодируются. Если ниже, то Ш и С начинают люто шуметь, при этом на ультра-высоких добавляется какой-то рваный шум, будто биткрашер навесили.
Почему макак не запилит автоматическое пожатие картинок в ЖИПЕГ? С возможностью покрутить качество или вообще не пожимать, примерно как в дашчане. Заебали картинки в 15 метров.
>>2802916> Интересно обоснование этого тезиса.Может быть бы ты загуглил?https://minds.wisconsin.edu/bitstream/handle/1793/45041/ECE%20790%20Hsin-Yu%20Chen%20project%20Report.pdf?sequence=1&isAllowed=yНо есть некоторые: НО.То, что он описывает по поводу памяти и синхронизации между КПУ и ГПУ - я не могу сказать что и не актуально, и что актуально.Т.е. изменения с момента публикации исследования в GPU были, да и производительность увеличилась раз так в 500+ плюс память так же быстрее стала, не говоря о чипах и так далее...Но и процы тоже быстрее стали на самом деле, не в 500+ раз, но в раз 5+ точно...
>>2756561>Популярность и распространённость — вот что действительно важноТы понимаешь, что "популярность", это быть одним из первых и лучших в чем-то и не сдаваться до конца. А не стек технологий...это касается вообще всего о чем ты слышал:nginxwinrarkasperskynortonwindowsdebianubuntuда любой популярный (очень популярный) софт возьми...Тот же AIMP...Я очень хорошо помню как он появился...Он появился когда уже WinAMP всех заебал.Аимп выглядел свежо, дохуя фич было, реально мощная альтернатива была всяким jetPlayer, Light Alloy, и так далее...Тем более WinAMP... В ту же пору появился и deadbeaf кстати...
>>2686610 (OP)решил пожать 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%, как в handbrake7.) идеально что бы и встройка напрягалась8.) нужно сохранять либо рядом либо в другой папке все сброшенные видосы.И вот мы подобрались к тому, что только одна софтина справилась с этим всем -> FormatFactory.Поэтому да - я рекламирую её, как годноту которая просто работает из коробки и делает всё что лично мне было необходимо для 100гб архива прона выкаченного с порнолаба.Результаты - несколько часов ебли.Около часа конввертацияВ результате получил на 64% меньше размер (36гб, против 102 изначально), при том же качестве визуально видео и аудио.
Аноны, есть ли в ffmpeg возможность сделать максимально компактный видеоролик по схеме?1. Вступление ролик12. Цикл ролик23. Окончание ролик3Видел, что зацикливали анимации без увеличения объема, а такое можно?
>>2804258Причем тут это?Вот же делали зацикленный клип без потери прстанства >>2778945Можно ли сделать то же самое, но с вступительным блоком и завершающим?
>>2804538Понятно. Только этот поток не занимает пространство, т.к. один фрагмент повторяется на протяжении всего ролика. Я на 100% уверен, что кодек позволяет нелинейно ссылаться на кадры и можно собрать ролик из циклических фрагментов, которые будут занимать только свой кусок пространства, а не копироваться на весь клип.Только как это сделать я не знаю, вот и спросил.
>>2804186>при наличии охуенного и открытого 7z Который настолько охуенен, что целиком распидорашивается от малейшей битовой ошибки.
>>2805017> малейшей битовой ошибки.Так-то да, 7z не умеет, но для подавляющего количества задач это не требуется.А ты сам где это реально применяешь?
>>2805300Из-за этой хуйни перестал бэкапы жать в 7z. Потому что бэкапы на каком только говне не хранятся.
>>2780060Когда уже вымрут все использующие i и j в циклах вместо осмысленных имён.>>2805017> целиком распидорашивается от малейшей битовой ошибкиПро такой параметр как размер блока в курсе? Или ты там опять базу данных в единственном экземпляре в режиме непрерывного сжатия жал?
Погонял avif на манге, заебись жмёт. Правда времени дохуя уходит и оперативку забивает моментально, но это не главное. Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.По шкале квантизации от 0 до 63:Цветные картинки жмёт заебись в пределах 10-20 с сохранением отличного качества при размере в 2-4 раза ниже чем жипег.Если жать чб/серую мангу с этими настройками, жмёт так же в 2-4 раза.Но если на чб/серых поставить 50-55, жмёт просто охуительно, почти в 10 раз, при этом визуально почти ничего не меняется.Но если на 50-55 жать цветные, то шакалы просто пиздец.И как мне, блять, сделать так, что бы из 250гб манги пожать отдельно цветные на одних настройках и чб отдельно на других настройках, при этом не вытаскивая пикчи руками из соответствующих папок, чтобы всё оставалось на своих местах?
>>2808584>Проблема остаётся в невозможности правильного определения степени сжатия для разного содержания.Надо ещё и размер пикчи учитывать.
>>2808584Нашкрептах за пять менут. Имаджмагик может посчитать тебе гистограмму, если на ней буду цвета отличные от серого то картинка цветная. Ну и разрешение так же.
Господа шакалы, посоветуйте, в какой lossy кодек лучше жать музыку - aac-lc или opus? А может что-то другое? Нужна хорошая поддержка тегов в Windows 10 и Android 7.0+ и поддержка софтом и хардом. Кроме того, интересно, насколько сильно накапливаются искажения при пережатии из mp3 320k?
>>2811635Из 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 баксов, там уже третья версия вышла.
>>2811952Потестировал, шиндовс 10 из коробки до сих пор не умеет в теги vorbis (хотя полная поддержка opus добавлена год назад), на андроиде с этим тоже есть некоторые проблемы (везде решается установкой стороннего плеера). Наверное, всё же буду жать в AAC, с ним нигде нет проблем, а на качество на низком битрейте мне всё равно, т. к. музыку жму в 256k vbr (мне не нужно максимальное сжатие, просто что-то лучше древнего mp3 и его чехарды с тегами).
>>2817218нет смысла никакого.Мимо, анон который пережал огромный архив музла в разные форматы, а теперь страдает от этого. Потому что нигде, кроме плеера эти форматы и нахуй не нужны.Тоже касается и фото.Хранить что-то в современных форматах можно лишь для АРХИВАЦИИ, но не как файлы, которыми изредка, да пользуешься, тем более если пользуешься регулярно. Ебли дохуища.
>>2817281>лишь для АРХИВАЦИИ>кроме плеера эти форматы и нахуй не нужныу плееров память не резиновая, ты как бы сам должен это знать, раз юзаеш. У телефонов и смартфонов как бы тоже. но те хотя-бы aac поддерживают (кроме артефактов древности), а смартфоны на android ещё и в opus могут.
>>2817218Для этого исходник нужен, а не этой чушью заниматься, из одного lossy в другой. Даже неизвестно какими способами всё это доставалось, в каком виде это было, с каким софтом, на каких сэмплах писано. Сервисы не особо то брезгуют и за исходник считают и lossy, которые потом же пережимают, набив еще больше искажений. это же касается и людей, кто рипует. Впрочем, что тут говорить, ты и сам это предлагаешь, а потом такие же это выкладывают, с друг другом делятся. Получается нескончаемый круговорот с последующим даунгрейдом. Представь что у тебя одна из этих вариаций, теперь ты предлагаешь из "этого" снова что-то ужимать. Самое банальное и частое: 320 лейбл -> 256aac айтюнс -> V0/V2 бесплатное, а теперь это у тебя и ты со своим>если уж пережимать так хотя-бы в 160k, если не меньшелол. разочарую вас, наверное, но такой клоунады lossy релизов в интернетах/сервисах - везде и всюду.>>2817281Я не вижу в этом сложностей, популярные плееры поддерживают это из коробки, как пекарен, так и мобильные. Да и музыка и так и сяк только в плеерах используется, где еще то и зачем.>>2811952У тебя устаревшая, последняя это 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 умеет).
>>2817644>>2817752вы не понимаете нихуя.Пишу ещё раз. Смысл имеет только архивация для хранения, либо максимум для воспроизведения, не более (и то, с проблемами).Я пережал огромную библиотеку медиа-файлов которые я слушаю\смотрю\читаю\просматриваю.Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопу. Потому что даже современное лицензионное ПО не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.Всё остальное - впизду, нахуй блядь.
>>2818559>Потом по работе понадобилось запилить клипчики на ютуб, фш, AF, и так далее - и тут я сел на жопуСам ты нипанимаеш. Ты сел на жопу не потому что форматы плохие, и даже не из-за кривого ентерпрайзного софта, а потому что ты lossless исходники удалил без бекапа. Страдай теперь, сам виноват.
>>2818559Имплаинг что кто-то кроме 0.01% потенциальной аудитории на ютубе заметит разницу, если в клип воткнуть 3 раза пережатый звук. Лишние проблемы себе создаёшь на ровном месте.>не поддерживает эти всякие ваши форматы. Причем проблема не только в этом, ещё хуже в том, что софт который нужен для работы - часто вообще не поддерживает ничего кроме: jpg, mp4, gif, png, bmp, mp3, wav.Ну так пережми обратно в поддерживаемые форматы и отложи в сторонку, на время работы, а потом удали нахуй. В чём проблема-то? Или аудиофил дохуя?
Ради интереса сравнил 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 и выше.
>>2819466Ну да, всё правильно. В митоле очень высокая плотность высоких частот из-за гитар с дисторшеном и громких железок. Поэтому все лосси кодеки жиденько обсираются при недостаточном битрейте. Для себя нашёл минимум для митола и всякой сложной электроники - 96 VBR Opus и 160 VBR Vorbis. Ниже - на опусе начинается сужение стерео на высоких частотах (широкие тарелки, например, начинают звучать ближе к центру, теряется пространство), а на ворбисе ниже 160 начинают обрезаться ультра-высокие (можно заморочиться и посмотреть каждый битрей через spek).
>>2819252Всю жизнь кинчики оставляли сжимать на ночь, тоже мне срок. Когда речь идёт о "сжал один раз" - "скачал миллион раз" то как вполне себе затраты окупаются.
>>2819745А вас не смущает перманентный апсэмпл из 44 в 48 в опусе? Это вообще хорошо для качества? Хочу определиться с форматом, но вызывает вопросы. mp3/aac отпадают.
>>2820795>Это вообще хорошо для качества?Это похуй для качества. Не забивай голову аудиофильскими бреднями.мимо-звукач
>>2820805Для lossy формата это похуй для качества. Ты от сжатия больше теряешь, чем от передискретизации.
не знаю, как я сюда попал но на всякий случай спрошукак порезать АПЕ фубаром, если он дает файл целиком, без треков? сторонний софт не хочется ставить
>>2820795Сама передискретизации в большую сторону - операция без потерь, спасибо за это Котельникову. Проблема в том что после передискретизации происходит повторное квантование. Но на фоне сжатия - это потери ультрамилипиздрические. Что-то уровня дроча на джиттер-коррекцию. Можешь не забивать голову.
>>2820977Cue файл вбрасывай в фубар, увидишь треки, выделяешь их и жмешь конвертацию в нужный тебе формат. Для поносного апе в фубар еще и плагин ставить нужно, да и сам апе лучше на "так" заменить - лучше и не столь требователен, быстрее сделает. А раз плеер не поддерживает, то надо выбирать кастомный режим, прописывать путь до mac.exe и вводить нужные ключи вручную, а их еще надо знать. Сам mac.exe еще и скачать нужно, а официально он только в виде инсталятора есть, что тоже ебанутость. Я не советую этот формат, никаких плюсов, пережми его в любой другой, какой нравится.А можешь просто CUE Tools поставить, это гораздо проще к освоению и ничего уже не требует.
>>2821293aac ожидаемо соснул у opus и vorbis на 64kbps. Хотя для митала ни тот ни другой на таком низком битрейте не подходит, тарелки и гитары теряют ширину резко.
>>2821349Надо заметить, что здесь используется профиль Low Complexity (LC), который не использует специальные фильтры для низких битрейтов.
>>2686610 (OP)Объясните чайнику, пожалуйстаЧто лучше 264 или 265? Важно, впрочем, качество приближенное к оригинальналу.
>>2821947Просто только недавно об этом вообще услышал.И пиздец статьи и статьи, столько инфы, а нахуй ничего не понятно
