Comments 114
Главные плюсы
У вас при подготовке текста куда-то пропал блок с минусами и последствиями процесса "шла битва за каждый байт и приходилось придумывать всё новые и новые форматы"
статья прикольная, но где-то потерялись моменты, где сжимать точно не нужно и до каких размеров
тема png не раскрыта
PNG без потерь, под капотом фильтрация для предсказания по трём соседним пикселям + DEFLATE
Технически лучше чем GIF и BMP, на сегодняшний день сожран WebP как и большинство других растровых форматов.
PNG не сожран, как никак единственный стандартный формат без потерь качества сейчас.
На одном крупном сайте, где художники продают картиночки, без объявления нововведений сделали пережатие в WebP. Большинство, котрое просто скроллит картинки, конечно не заметило. Однако среди тех, кто продаёт и покупает, начались брожения - художники стали картинки прятать от сжатия сайта в аттачментах, кто-то из богатых клиентов громко объявил об уходе и стал переманивать на другую платформу.
Сайт немного повозился с WebP, сделал ему lossless-сжатие, но, боже, кому нужно скачанный WebP коллекционировать? Чтобы он открывался в браузере вместо просмотрщика картинок (который его не видит вообще), да ещё и гадать - lossless он или тебя развели с lossy.
Так что от WebP там отказались.
Технически WebP сложнее в реализации, но степень сжатия без потерь там обычно выше чем у PNG. В большинстве случаев на сайте можно обойтись только WebP, полностью заменив JPG/PNG/GIF.
Но там же совсем крохи разницы будут, если сжатие без потерь там и там. А плюсы в чем?
Да, без потерь он всего на 30% меньше, чем PNG. Можно не заморачиваться.
Проблема WebP не в алгоритме, а в его социальном статусе - он до сих пор воспринимается как формат для веба, а не как формат для хранения. И пока его не начнут нативно поддерживать все операционные системы и графические редакторы на уровне PNG, он так и останется нишевым решением для оптимизации сайтов
На одном крупном сайте, где художники продают картиночки, без объявления нововведений сделали пережатие в WebP.
Поделитесь, пожалуйста, ссылочкой.
Мне для коллекции.
patreon.com это (но думаю, что вы искали что-то другое)
Я собираю примеры.
https://www.reddit.com/r/patreon/comments/1iythio/patreon_started_brutally_compressing_my_images/ - оно?
Есть где-нибудь описания событий?
Да, оно. Началось 27.02.2025, закончилось примерно 06.04.2025. Между этими датами происходили какие-то шатания: то там ломали поддержку заголовка accept без webp, то запихивали webp в файлы с расширением .png, то возвращали png ненадолго. Хронологию событий вряд-ли кто вёл, но можно найти посты на патреоне за то время, где в каментах люди сообщают о проблеме, и увидеть как за тот период художники стали пользоваться аттачментами. Я так вообще из дискорд-сообществ это наблюдал.
Может и правильно, но если у вас в 2025 подсмотрщик картинок не открывает WebP - его надо поменять.
на сегодняшний день сожран WebP
А мужики-то не знают! (ц)
Я как-то решил ради интереса пережать 1 минуту скачанного 4К видео фильма (6 разных фильмов было) в
H264 -preset VerySlow
H265 -preset placebo
AV1 -strict experimental
с помощью ffmpeg на процессоре.
И знаете что, умолчу про время кодирования AV1, но качество круче всех оказалось у H264.
Далее, что для меня удивительно, почти всегда, по размеру выигрывал H265.
Да, размер H264 оказался примерно на треть больше, но я свой архив фильмов оставил в нём.
как оценивали качество?
С помощью того-же ffmpeg один и тот-же кадр сохранял в PNG.
На телевизоре разница конечно-же не заметна, но вот на мониторе при переключении слоёв в редакторе изображений, вообще без проблем. Качество H265/AV1 вообще никакое.
Но готов сделать сноску, для перекодирования записи монитора, если это текст, AV1 для меня топ.
Начиная с h264 у кодеков есть оптимизации под текст. Там туча опций.
У вас скорее всего роль играли дефолтные настройки ффмпег
Блин, дайте пожалуйста ваши правильные команды для того, чтобы качество видео H265/AV1 сравнилось с H264.
Для сравнения, базовая команда для H264 была такой:ffmpeg.exe -i "видео.фильм" -c:a copy -c:s copy -map 0:0 -map 0:1 -vcodec libx264 -preset VerySlow
Меня все уверяют, что новые кодеки лучше, но не могут привести доказательства.
Они не лучше, у них меньше битрейт. Psnr метрики смотрите, а не глазами. И вообще зачем вам кодеки?
Старый контент транскодировать только портить. Для нового используйте самый передовой кодек, если нет вопроса совместимости
Psnr метрики смотрите, а не глазами
Вот так точно делать не надо при сравнениях со старыми кодеками. они активнее жрут детали и очень легко могут дать psnr выше чем у нового. Я в своё время немного игрался со сжатием, так для определённых семплов (типа старых фильмов) я на своём недожипеге легко получал "лучшее" качество чем h265 вообще без каких-либо оптимизаций под тест.
А так да, максимально качественный исходник жмётся максимально новым кодеком, жизнь становится проще.
psnr на низком битрейте не будет показателен. надо брать несжатый исходник и делать битрейт побольше (ну не 1мбит)
Конкретно там был крёстный отец, пожатый h265 из исходников до 9500 мбит/с с прицелом на максимальное сохранение деталей. Против него был мой недожипег, не помню с каким, но, очевидно, сравнительно огромным битрейтом и, очевидно же, сильно худшим качеством. Мой недожипег выигрывал. Оно и понятно, он всё зерно замылил, вот, вроде, шума и немного, и метрика "хорошая".
так если битрейт выше, то и качество выше. я вот сейчас наделал вариантов из студийного мастера с помощью хендбрейк. вопервых там не выдерживается битрейт, но примерно совпадает. по метрикам разница между кодеками становится сильно заметна только на низких битрейтах (ну контент такой видимо). psnr даёт хороший результат при битрейте от 8М на 264, ниже всё плохо. и глазами и метрикой. хотя psnr убогая метрика.
вообще все эти изыскания в кодеках удел Нетфликс, Ютуба и спутниковых b2c операторов (там еще интереснее). цифровой релиз фильма это отдельная история и обьем файла там не так важен (блюрей большой)
Вы ж даже битрейт не указали, фиг знает что там у ffmpeg по умолчанию прописано
Сравнивать надо хотя бы или с одинаковым средним битрейтом (тогда предполагается, что новые кодеки будут качественнее), или с одинаковым качеством (тогда предполагается, что новые кодеки дадут меньший средний битрейт)
Ну и в любом случае повторное сжатие уже сжатого контента неизбежно приведёт к дальнейшему ухудшению качества независимо от кодека, для сравнения кодеков нужно брать изначально несжатый исходник
Я указал хоть что-то, хотя бы пресеты, у H264/H265 они отвечают за максимальное качество. Я указал, что перекодировал 4K фильм.
У меня вышло что H264 с максимальным качеством явно лучше H265.
Вы же опять о сферическом коне в вакууме из, не побоюсь этого слова, МУСОРНЫХ статей, которые хвалят новый формат, но не приводят ни команды ни свой опыт.
Поделитесь, что вы перекодировали для сравнения и Вашу команду для H265. Я перепроверю у себя и если Вы правы, то на словах от меня БЧС Вам непременно будет.
Пресеты отвечают за скорость кодирования, один и тот же пресет даст абсолютно разные качества на разных битрейтах
Наличие 4К никак не отменяет того факта, что этот ваш фильм почти гарантированно является сильно сжатым (никто ж вам не даст настоящий исходник)
Вообще-то почти на 100% гарантировано, что Вы нигде не получите не сжатый исходник.
Я взял для перекодирования максимально качественную картинку, более 4К мне негде смотреть.
Поэтому опять вижу словеса в небеса и не более.
Давайте перекодируем какой-нибудь Ваш самый нулёвый исходник, но не мультик. И сравним. Я буду только рад, если удастся сэкономить место на диске, без потери качества в сравнении с H264.
H264 оказался примерно на треть больше
нечестно получается. итоговый файл по весу должен совпадать.
AV1 -strict experimental
это не пресет
Как уже писали, если видео изначально сжато, то могут начать происходить всякие странности.
Кстати, я сам затестил только что кодеки (но на мелких отрывках, input: дрон летает над пляжем, 4к, х264 100М битрейт). Одинаковый итоговый вес, настройки кодировщика эквивалентны. Сжатие до 10М битрейта, чтобы было наглядно.
х264 ожидаемо убил картинку напрочь. А вот х265 и ав1 почти не отличались. Вот это меня удивило. Хотя... наверное, от типа контента зависит.
Что значит нечестно?
У Вас в приоритете битрейт, у меня в приоритете качество.
Размер на треть больше при качестве гораздо лучшем у H264 меня устраивает.
Вы же гонитесь за размером файлика.
у меня в приоритете качество
Тогда почему вы вообще что-то куда-то кодируете?
Просто ничего не делайте — и качество останется максимально возможным
80 гигов видео для любимого фильма многовато, с учётом того, что такой не один, пытался оптимизировать коллекцию.
Разницу в кадре "оригинала" 4K и H264 надо выискивать на мониторе, а вот H265, как оказалось, выискивать не надо, всё видно очень хорошо. Хотя поток на кодирование обоим кодекам отдавался идентичный.
На примере JPG картинок, качество 80% от исходника меня устраивает, разницу я должен искать, а вот 50% я вижу моментально, если переключать слои. Опять же, если не брать пограничные случаи типа текста, где всё гораздо жёстче и там наверняка будет PNG.
80 гигов видео для любимого фильма многовато
Значит вы согласны на ухудшение качества ради уменьшения размера (то есть битрейта).
Какова длительность этого любимого фильма и сколько конкретно для вас не «многовато»?
Все мои посты говорят о том, что я согласен на то, когда не вижу разницы между исходником и целью.
Разницу в H265 я вижу отчётливо и не напрягаясь при покадровом изучении, H264 - не вижу.
Просто ничего не делайте — и качество останется максимально возможным
Это очень правильное замечание, потому что не существует абстрактного УЛУЧШЕНИЯ. Есть ИЗМЕНЕНИЕ которое должно изменить один параметр, попутно изменив другие. И запланированное нам изменение будет УЛУЧШЕНИЕМ, а незапланированное - УХУДШЕНИЕМ,
Ну так поизучайте опции кодека, запустите его так чтобы он знал, что ему можно ради качества выплюнуть "на треть больший по объёму файл", потом сравнивайте.
А то получается, что Петя копает в полтора раза быстрее Васи, но Пете вы позволяете копать час, а Васе два, а потом заявляете, что Вася больше Пети копает.
То есть, не по количеству изменившихся пикселей, а органолнептически?
Берётся скриншот оригинала и скриншоты всех вариантов перекодирования. Всё в PNG.
Далее на нулевом слое редактора изображений оригинал, а затем получившиеся варианты. Ну и перещёлкиваем их.
Квадратики видны без лупы. Никого из милиции даже возбуждать с этим девайсом не пришлось. Разница видна почти моментально.
Опять-же уточню, я не кодировал мультик Остров сокровищ, я специально выбирал художественные сцены с мелкими деталями. Старался, чтобы в кадре были волосы.
во-первых берите не скриншот, а I-frame (AVidemux в помощь)
во-вторых в профессиональной среде не используют ффмпег для кодирования :)
А какой смысл брать I-фреймы, если зритель в основном видит P/B-фреймы, которых большинство?
чтобы нивелировать влияние плеера\декодера
Оно вряд ли различимо на глаз. Энкодер и так делает проход декодером, и адаптирует результат как раз чтобы не получалось, что после декода что-то неожиданное было.
я больше про то, чтобы у него был один и тот же кадр. и специфику плеера не надо исключать (улучшалки всякие как вариант). на счёт софта конкретно не скажу. а вот телевизоры и stb что только не делают по-умолчанию
Я нигде не утверждал что я профессионал.
Я везде просил профессионалов помочь мне со строкой для перекодирования.
Я, как любитель, тупо взял 2 пресета заточенные на максимальное качество и увидел, что H265 это не то, что я хотел получить. Мыло мне не надо.
А все профессионалы так и молчат. Хотя я им предложил сделать тест на их исходном видео с их командами, чтобы доказать обратное. Но это очень секретное знание, которое судя по ответам недоступно даже профессионалам.
Поэтому остаюсь на H264.
Я везде просил профессионалов помочь мне со строкой для перекодирования.
И когда вас попросили озвучить конкретные требования, которым эта строка для перекодирования должна соответствовать, вы их озвучивать отказались. Неудивительно, что все мало-мальски компетентные профессионалы решили вас проигнорировать
Такое ощущуение, что Вы отвечаете на что-то своё, не читая мои буквы.
Конкретные требования были озвучены неоднократно, избавиться от квадратиков по сравнению с пресетами максимального качества у 264/265.
У 264 с максимальным пресетом, "квадратиков" нет, у 265 есть, но объём меньше примерно на треть.
Задача такая, при сравнимом качестве 264/265 получить меньший размер на выходе. Но качество на первом месте, только потом битрейт и прочее.
Ещё раз другими словами, мы не должны терять в качестве видимом на глаз и в тоже время на только на втором месте стремимся сэкономить на объёме файла.
избавиться от квадратиков
качество на первом месте
Вам на всё это уже был дан ответ: просто ничего не делайте — и у вас останется исходник в максимально возможном качестве
меньший размер на выходе
Насколько меньший? Если 80 гигов сожмётся в 79.999 гигов — это устраивающий вас результат? Если нет, то почему?
Так если не используют ффмпег, какую команду вы хотите?
MSU VQMT Free вам в помощь, и вот эта статья elecard.com/ru/page/article_interpretation_of_metrics
265 куда качественнее, хз как у вас так получилось. видео с экшн камеры в 1440р@60 вывожу. Для 264 нужно не менее 100мбит чтобы не было ощутимых артефактов, а для 265 достаточно 20. С фильмами попроще в целом потому что там ДД куда ниже, нет ярких насыщенных цветов и жмутся они эффективнее из-за этого
Сильно зависит от самого видео и так же сильно от настроек сжатия под конкретное видео. Единичный случай ни о чем вообще не говорит
Все правильно сделали. Для домашнего архива, где место не так критично как качество, сохранение в максимально близком к оригиналу виде (или с минимальным пережатием проверенным кодеком) самая здравая стратегия. Пережимать уже сжатое все равно что делать ксерокопию с ксерокопии, лучше не станет
Использование видеокодека для фото в мобильных устройствах решает вопрос энергопотребления, и упрощает аппаратную реализацию кодера.
Ответ прост: если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт. Интернет времён 90-х просто не справился бы с таким объёмом данных.
Неправда, тем более про 90-е
Не прижился, ещё на лекциях @3Dvideo нам рассказывал, что формат более приятен человеческому глазу, ибо вместо пиксельных артефактов у него происходит плавное размытие. Вейвлетное кодирование, однако
Думали, что приятен, оказалось, что не особо: рингинг делает изображение напоминающим страшный сон или галлюцинацию.
Слишком мало преимущество в сжатии при заметном увеличение сложности (тогда это было важно) и не самой высокой гибкости
вейвлеты далеко не панацея. Наверное встречались с форматами wmv (windows media video) и wma (аудио)? Так вот, был ещё wmp для изображений. На моднейших вейвлетах, как и остальные два. Только он оказался заметно хуже jpeg-а при том же размере файла или заметно (процентов на 30) больше при одинаковом качестве.
Sorenson Spark - это реализация H.263. Как и Divx и Xvid.
А файлы стали меньше...
Меня пробило на персональные видеорегистраторы. Для велосипеда и для ношения. Да ещё с художественным видео, чтобы потом, сидя зимой, можно было погружаться в лето, в поездку на велосипеде. И столкнулся с таким, который использует не просто h.264, а ещё и пишет с VBR. Что это даёт? 5 минут могут занимать не 700 мегабайт, а бывает что и 40, и даже меньше. Конкретно у этого видеорегистратора есть минус - слишком низкая частота видеопотока. Вместо листвы зелёная масса, номера читаются только вблизи.
Да, h.265 даёт маленький объем видео, а также нередко потерю деталей. Как-то писал про то, что перекодировать большое видео не смог, снятая на видео белка просто исчезает при попытке уменьшить объем видео до приемлемого размера.
Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука, постоянный или переменный битрейт. Также есть проблемы с перекодированием видео, снятого при плохой освещённости. И вот такая сборная солянка помогла бы делать видео с приемлемым качеством и, возможно, с минимальным объёмом для сюжетов в видео.
Это ж надо вначале понять, что важно на видео, а что нет. Сегодня в парке фоткал белку, так там другие люди были рядом, вот их можно было бы и убрать.
Вы это серьёзно? Необходимо получить видео, максимально приближённое к исходному. А не отредактированное с убиранием или добавлением чего-то. Кодирование, а не редактирование.
А вот видео с бегущей белкой кодируется так, как будто это движение чего-то вообще не имеет никакого значения, и безжалостно удаляется.
Плюсую. Мне не нужно редактирование. Фигня на самом деле с форматами стала.
А не отредактированное с убиранием или добавлением чего-то. Кодирование, а не редактирование.
Полагаю, скоро это всё будет упаковано в одни функционал и кнопку "улучшить качество", а разработчики сервиса/софта просто не поймут о чём Вы говорите.
"Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука"
ОК, возьмём звук. Пусть у нас... Видео где барабанщик играет на сцене, у него развешаны тарелки, они дают множество высоких частот.
Если ваша задача продемонстрировать качество тарелок - нужно будет сохранить частоты, а самого драммера можно будет и размыть. А если вам пофиг, что там звучит - а барабанщик ваш друг/ребенок на которого хочется посмотреть, то надо сохранять качество видео. А если вам интересна игра света от софита, то вообще фокус будет на чем-то еще.
Кодирование с потерями оно такое - теряется то, что неважно, а что неважно? Вопрос к человеку.
Думаю что если грамотно создать контейнер (формат видео с кучей различных кодеков), то нормальная программа сама сможет разобраться, где нужно писать 96 кГц при 24 битах, а где и поменьше битрейт пойдёт. Не везде же тарелочки с флейтами звучат, и нет необходимости отдавать огромный объем под звук. Думаю что и с видео разберётся. И не будет из темноты выходить призрак без ног, с каждым шагом отращивая их. В конце концов даже если была бы возможность делать это вручную, уже было бы неплохо.
Думаю что давно пора создать ещё один формат, в котором в одном видео чередовались бы кодеки, частота видеопотока, звука, постоянный или переменный битрейт.
Называется Matroska (MKV). Правда, не уверен, что такого Франкенштейна хоть какой-то плеер сможет проиграть, слишком пограничный случай. А вообще современные кодеки с переменным битрейтом должны подстраиваться под изменения сцены.
MKV проиграть в смартфоне могут, во всяком случае VLC ни с какими вариантами не вешался, в компьютере тоже, но это не кодек, это контейнер. И речь идёт о том, чтобы в одном видеофайле были разные кодеки.
Теоретически h.265 и av1 должны быть отличными. Они как бы то, что надо, но не совсем что надо. Сцены разные бывают. И для сохранения некоторых сцен перекодированный из h.264 в h.265 видеофайл получался больше исходного размера. Речь же идёт о сжатии, а не об увеличении объёма файла. Возможно именно эти сцены для видео лучше оставить без сжатия, в том же h.264, но при обычном кодировании конечный файл здоровенный получается, а основное тело видео прекрасно сжимается этим h.265 с меньшим битрейтом. Вот о чём речь. То есть хотелось бы что-то вроде h.265 -h.264 (оригинал) - h.265. Уже по- разному пробовал. Либо теряются детали, либо смысл в перекодировании теряется. Не хотелось бы всё на дисках огромной ёмкости хранить. Будь то HDD или оптические. Смысл в том, чтобы уйти от объёма, сохранив качество.
За объем у нас отвечает битрейт, за качество он же, но если для уменьшения объёма битрейт нужно уменьшать, для сохранения второго нужно увеличивать. Сейчас же всё видео пишется одним кодеком либо с одним битрейтом, либо с переменным. Остальные варианты, как показала практика, чаще всего не варианты. Итог - валяются 40 гигабайт видео всего лишь из-за одной короткой сцены. Без перекодирования мегабайт 20. То есть из-за такой маленькой сцены конечный объем раз в ...дцать больше, чем может быть. В других случаях смирился с потерями, не художественное видео. Но и там, конечно, не хотелось бы терять детали.
Называется Matroska (MKV).
«Матрёшка» же!
Потребительские форматы h26* и пр. не созданы для транскодирования. Берите топовый регистратор с хорошим кодером. Либо у вас должен быть большой запас по битрейту, скажем 30Мбит транскодите в 10.
Камера до 60 Мбит. Я не помню с каким разрешением снимал. Проблема в деталях, из-за которых из-за монокодека и монобитрейта конечный размер файла большой.
Вот я и мечтаю, что у кого-нибудь мысль в голову придёт разработать контейнер (если точнее - кто-то прочитает что пишу и создаст это), в котором будут и несколько кодеков, и несколько битрейтов. А где-то просто чтобы был кусок оригинала.
Для тёмных сцен нужен большой битрейт, для светлых меньше. И переменным битрейтом это не решается. И даже фильтры не везде приемлемы. Есть ситуации, когда нужно создать видео с парой кусочков по 9 ГБ, и между ними обзор, где 40 мегабайт будет выше крыши. А вот из-за кодека и битрейта этих 9-гигабайтных кусков видео может увеличиться ещё гигабайт на 60 для сохранения качества. Вот и получаются обычные текстовые обзоры со вставками в окошках проигрывателей, либо ссылок на облако, откуда можно скачать эти куски видео.
Переменный битрейт именно это и решает. Можно сделать видео, где одна минута будет ужата в хлам, а другая будет неотличима от оригинала. Только обычно все хотят достигнуть в среднем по видео одинакового качества, если нужна эффективность качества на бит. Или постоянного битрейта, если есть ограничения на скорость записи или передачи видео. Потому есть только настройки качества в среднем и верхней или нижней границы битрейта. Ведь угадать когда тебе будет нужен высокий битрейт - это надо экстрасенсом быть?
Вы примерно представляете, как это работает? Сделаете нижнюю границу низкой, а верхнюю на пару порядков выше, кодек все статические сцены сделает под нижнюю границу, а быстрые раза в 1.5-2 выше сделает битрейт. Вот и всё.
Вы с преобразованием Фурье знакомы? Познакомьтесь, это и есть нужный экстрасенс.
примерно представляете, как это работает?
Только примерно. Энкодер приблизительно оценивает сложность статического кадра, или разницу между кадрами, или сложность движения, и сохраняет каждый соответствующий тип кадра с разной точностью.
все статические сцены сделает под нижнюю границу, а быстрые раза в 1.5-2 выше сделает битрейт. Вот и всё.
А вам нужно наоборот? Насколько я понял, вам нужно записать статическое видео темноты около часа где ничего не происходит, а потом мелькнувшую перед камерой белку, так чтобы она не размылась - самое то для VBR. Можно наверное количество ключевых кадров уменьшить.
Это всё решается в рамках h264. Просто у вас самый примитивный кодер, как на деш телефонах. VBR с прицелом на качество, супер длинный GOP. Двупроходное кодирование с буфером в 5сек для анализа и пр. Есть еще момент что VBR будет ограничен буфером на плеере в итоге. Так что как в любом случае будут ограничения. Попробуйте CBR с максимальным битрейтом и потом подбирайте кодек, если есть задача экономии диска. Но было бы разумней не транскодировать, а вырезать мусор (без транскодирования) после сьемки
Ожидал увидеть в статье описание алгоритмов, которые позволили новым форматам обойти jpeg. Прочитал СЕО воду.
редко задумываемся, почему одинаковый кадр может весить в три раза меньше, но выглядеть так же.
В качестве примера этому можно взять заглавное изображение с котэ.
Это PNG на 115 Кб. Если натравить на него OptiPNG с ключом -o7, то размер снизится до 79 Кб, а если сохранить изображение как 80% раствор JPG, то и вовсе до 42 Кб.
если бы мы хранили изображения в их исходном виде, даже одна фотография занимала бы сотни мегабайт.
Возьмём кадр в разрешении 8K (7680x4320), сделаем каждый пиксель 24-битным, никакого сжатия. И даже в этом случае у нас получится 768043203 = 99 532 800, т.е. 95 мегабайтов. А тогда подобных гигантских разрешений и в помине не было.
Память стоила дорого
Какая память? Дисковая, оперативная?
В эпоху dial-up-модемов это было как-то так: вы видели, что фото точно загрузится, и могли подождать, пока прогрузится лицо собеседника из ICQ.
Ы?
Не было в аське никаких лиц в диалапную эпоху. Не генерируйте текст про то, о чём не имеете ни малейшего представления.
Instagram* и другие мессенджеры
Так это мессенджер? )
Соглашусь с другими ораторами, прочтя заголовок ожидал техническую статью, а получил мусор.
За кадром остался главный инженерный компромисс: битрейт против циклов CPU. AV1 сжимает отлично, но попробуйте закодировать им что-нибудь на слабом железе "на лету" и вся экономия выйдет боком через раскаленный процессор и севшую батарейку. Магии не бывает, есть только физика и математика
Домашнюю видеобиблиотеку всю переконвертировал в h.264/aac, как самый поддерживаемый формат для видео - проигрывается и на десктопных и на мобильных клиентах и в браузерах.
С другими вариантами не получалось "универсального" решения...
JPEG, HEIC и AV1 давно стали частью нашей повседневности
HEIC - это прерогатива айфонщиков, у меня ни одной картинки HEIC не хранится. А когда присылают, еще не сразу поймешь, что это, ищешь конвертер, чтобы посмотреть...
AV1 - первый раз слышу.
AV1 уже давно есть. Только у меня ни один конвертер/кодер не сделал ни одного файла в таком формате, постоянно ошибка. Только просмотреть могу. С heic на самсунге никогда с просмотром проблем не испытывал, равно как и на iPhone 7 с heif и hdr10+.
уже давно есть
Я и не говорю, что их еще не изобрели. Я говорю, что фраза
давно стали частью нашей повседневности
сильно преувеличена. Опять-таки, "давно есть" не равно "стали частью повседневности", потому что какова доля видео в таком формате? Я вот до сих пор не встречал.
проблем не испытывал, равно как и на iPhone 7
С чего бы там взяться проблемам, если это "их" формат? Проблемы у всех остальных, кому айфонщики фото скидывают, потому что нативной поддержки в ОС на ПК их нет. Сколько там айфонщиков по данным мвидиа? 25%? Вот для них - да - стали частью повседневности.
AV1 - первый раз слышу.
Youtube уже 2 года как перешёл по умолчанию для видео 1080 и меньше.
В heic снимает довольно много телефонов, если включить в настройках. На самсунг только в нём и снимаю, и много раз у каких-то китайцев видела
Так примеры с JXL под 85 и 90 не рациональны, он и на 70% качества покажет идеальный результат в сравнении с конкурентами и весить будет меньше.
В статье толком не раскрыт формат webp от гугла. Это, можно сказать, JPEG 2.0 каким он должен был быть. Тут вам и блоки 4х4 и 16х16, и альфа-канал, и нормальный алгоритм сжатия без потерь... Правда, прибитый гвоздями YUV 4:2:0
Пара замечаний. Во-первых, по заголовку - "почему файлы стали меньше". Не замечаю такого явления. Наоборот - когда-то нормально заходила авишка на 700 мегов полуторачасового фильма. Потом меньше 1,4 гигабайта на полный метр качать стало западло. Затем 2,1 гигабайта на полтора часа стало хорошим тоном. Сейчас полтора гига на 40-минутный эпизод сериала считаю в принципе приемлемым качеством, но не идеалом такового. Я понимаю, что разрешения увеличиваются, HD, то-се. Но "файлы стали меньше" - это не тру заголовок.
С изображениями то же самое. Когда-то в веб-мастеринге было железное правило - вся страница HTML должна весить не больше 100 килобайт, чтобы не задерживать пользователей. Сегодня бонтон другой - чтобы одна фотка на странице весила не больше 200-250 килобайт, дабы не задерживать пользователей.
Так что файлы-то становятся больше - другое дело, что если бы форматы не оптимизировали, они становились бы еще больше.
К сожалению, на многих ширпотребных одноплатниках поддерживается аппаратно исключительно h.264, попытки h.265 превращают видео в слайдшоу, про av1 и говорить нечего, ситуация еще хуже. Так что конкретно там прогресс не то чтобы высок. Если у кого-то есть более позитивный отзыв, пишите, было бы интересно узнать про конкретную программно-аппаратную конфигурацию у вас
Почему файлы стали меньше: форматы фото и видео (JPEG, HEIC, AV1)