Сейчас 2019 год, и нам пора бы принять решение относительно GIF (нет, речь не об этом решении! Здесь мы никогда не договоримся! — тут речь о произношении в английском, для нас это не актуально — прим. перев.). GIFы занимают огромное количество места (обычно по несколько мегабайт!) что, если вы веб-разработчик, полностью противоречит вашим желаниям! Как веб-разработчик, вы хотите минимизировать вещи, которые пользователям нужно скачать, чтобы сайт загружался быстро. По той же причине вы минимизируете JavaScript, оптимизируете PNG, JPEG, а иногда и конвертируете JPEG в WebP. Но что же делать со старичком GIFом?
Там, куда мы направляемся, нам не понадобятся GIFы!
Если ваша цель — улучшить скорость загрузки сайта, то от GIF нужно избавляться! Но как же тогда делать анимированные картинки? Ответ — видео. И в большинстве случаев, вы получите лучшее качество и экономию места в 50-90%! В жизни большинство вещей имеют свои плюсы и минусы. Когда вы заменяете GIF на видео, минусов чаще всего найти не получится.
Долой все GIFы!
К счастью, замена GIF на видео была обычным делом последние годы, так что все необходимые инструменты уже в ходу. В этом посте, я не стану изобретать велосипед, а лишь немного улучшу имеющиеся решения. Итак, вот суть:
- Возьмите GIF и переконвертируйте его в видео
- Закодируйте видео с помощью H.264 или VP9, т.е. сожмите его и упакуйте в MP4 или WebM контейнер
- Замените
<img>с анимированным GIF на<video>с роликом - Включите автовоспроизведение без звука и зациклите, чтобы добиться эффекта GIF
У Google есть хорошая документация, описывающая процесс.
Сейчас 2019 год
Сейчас 2019 год. Прогресс движется вперёд, а мы должны от него не отставать. До сих пор у нас было два варианта кодеков, которые широко поддерживаются во всех браузерах и инструментах для кодирования видео:
- H.264 — появившийся в 2003 и шире всего используемый сегодня
- VP9 — появившийся в 2013 и добившийся улучшения сжатия почти на 50% по сравнению с H.264, хотя как пишут здесь не всё и не всегда так радужно
Примечание: хотя стандарт H.265 — следующая версия H.264 и способен конкурировать с VP9, я не рассматриваю его из-за слабой поддержки браузерами, что показано на странице https://caniuse.com/#feat=hevc. Расходы на лицензирование — главная причина, по которой Н.265 не стал так же распространён как и H.264 и по которой консорциум Alliance of Open Media работает с кодеком без отчислений — с AV1.
Помните, что наша цель в том, чтобы уменьшить огромные GIFы до наименьшего возможного размера, чтобы ускорить загрузку. Это был бы странный 2019 год, если бы у нас в арсенале не появилось нового стандарта для сжатия видео. Но он есть и называется AV1. С AV1 можно добиться примерно 30% улучшения сжатия по сравнению с VP9. Лепота! :)
AV1 к вашим услугам с 2019 года!
На десктопах
Недавно поддержка декодирования AV1 видео была добавлена в десктопных версиях Google Chrome 70 и Mozilla Firefox 65. Прямо сейчас поддержка в Firefox глючит и может вызвать сбои, но дела должны изменится с добавлением декодера dav1d уже в Firefox 67 (уже вышел, а поддержка появилась — прим. перев.). Для деталей о новой версии читайте — dav1d 0.3.0 релиз: ещё быстрей!
На смартфонах
Для смартфонов аппаратная поддержка в настоящее время отсутствует из-за отсутствия соответствующих декодеров. Можно сделать программное декодирование, правда это приведёт к увеличению расхода батареи. Первые мобильные SOC с поддержкой аппаратного декодирования AV1 появятся в 2020 году.
И тут читатели статьи такие «так если мобильные пока нормально не поддерживают, зачем тогда использовать AV1?»
AV1 — довольно новый кодек, и мы находимся в самом начале его адаптации. Подумайте об этой статье как о стадии «пока вы готовите, народ подтягивается». Поддержка на десктопах сама по себе уже ускорит сайты для части аудитории. А старые кодеки можно использовать как fallback сценарий, когда на целевом устройстве AV1 не поддерживается. Зато по мере перехода пользователей на девайсы с поддержкой AV1, всё уже будет готово. Чтобы этого добиться, нам нужно создать тег видео, как показано ниже, который позволит браузеру выбирать предпочтительный формат — AV1 ->> VP9 ->> H.264. Ну а если у пользователя совсем старый девайс или навигатор, который видео не поддерживает вообще (что крайте маловероятно с H264), то он просто увидит GIF
<video style="display:block; margin: 0 auto;" autoplay loop muted playsinline poster="RollingCredits.jpg">
<source src="media/RollingCredits.av1.mp4" type="video/mp4">
<source src="media/RollingCredits.vp9.webm" type="video/webm">
<source src="media/RollingCredits.x264.mp4" type="video/mp4">
<img src="media/RollingCredits.gif">
</video>Создание AV1
Создать видео в AV1 несложно. Скачайте последнюю сборку ffmpeg для вашей системы отсюда и используйте команды ниже. Мы используем 2 прохода для достижения целевого битрейта. Для этого мы будем запускать ffmpeg дважды. Первый раз мы запишем результат в несуществующий файл. Это создаст журнал, который понадобится для второго запуска ffmpeg.
# Linux or Mac
## Проход 1
ffmpeg -i input.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-columns 2 -row-mt 1 -threads 8 -pass 1 -f mp4 /dev/null && ## Проход 2
ffmpeg -i input.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-columns 2 -row-mt 1 -threads 8 -pass 2 output.mp4
# Windows
## Проход 1
ffmpeg.exe -i input.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-columns 2 -row-mt 1 -threads 8 -pass 1 -f mp4 NUL && ^
## Проход 2
ffmpeg.exe -i input.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-columns 2 -row-mt 1 -threads 8 -pass 2 output.mp4Вот расшифровка параметров:
-i - Входной файл.
-pix_fmt - Используем формат 4:2:0 для выбора информации о цветности в видео. Существует много других возможных форматов, но 4:2:0 наиболее совместимый.
-c:v - Какой кодек использовать, в нашем случае - AV1.<br />
-b:v – Средний битрейт, которого мы хотим добиться.
-filter:v scale - Фильтр масштаба ffmpeg используется для уменьшения разрешения видео. Мы устанавливаем X:-1 что говорит ffmpeg уменьшить ширину до X, сохранив соотношение сторон.
-strict experimental - Надо указать, т.к. AV1 достаточно новый кодек.
-cpu-used - Ужасно названный параметр, который на самом деле используется для выбора уровня качества видео. Возможные значения 0-4. Чем меньше значение, тем лучше качество и, соответственно, больше время, которое займёт кодировка.
-tile-columns - Для использования нескольких тредов. Говорит AV1 разбить видео на отдельные колонки, которые могут быть перекодированы независимо для лучшей утилизации ЦПУ.
-row-mt – Тоже, что и предыдущий параметр, но разбивает так же на строки внутри колонок.
-threads - Количество тредов.
-pass - Какой проход сейчас выполняется.
-f - Используется только при первом проходе. Указывает формат выходного файла, т.е. MP4 в нашем случае.
-movflags faststart - Включаем быстрый старт видео, перемещая часть данных в начало файла. Это позволит начать воспроизведение ещё до полной загрузка файла.
Создание GIF
Для создания GIF я использовал приведенную ниже команду. Чтобы уменьшить размер, я масштабировал GIF до 720px в ширину и 12 fps вместо исходного видео 24 fps.
./ffmpeg -i /mnt/c/Users/kasing/Desktop/ToS.mov -ss 00:08:08 -t 12
-filter_complex "[0:v] fps=12,scale=720:-1" -y scene2.gifРезультаты тестов
Лучше один раз увидеть, чем сто раз прочитать, правда? Давайте убедимся, что AV1 — правильный выбор для наших целей. Я взял бесплатное видео Tears Of Steel, доступное здесь https://mango.blender.org/, и конвертировал его, используя примерно одинаковый битрейт для кодеков AV1, VP9, H.264. Результаты ниже, так что вы можете сравнить их самостоятельно.
Примечание 1: Если файл ниже у вас не загружается, возможно, вам пора обновить браузер. Я бы посоветовал браузер на основе Chromium, например, Chrome, Vivaldi, Brave или Opera. Вот последняя информация по поддержке AV1 https://caniuse.com/#feat=av1
Примечание 2: Для Firefox 66 в Linux вам нужно будет установить флаг media.av1.enabled в значение true в about:config
Примечание 3: Я решил не включать обычные GIF ниже из-за их большого размера и объема данных, который мог бы потребоваться для загрузки этой страницы! (Что было бы иронично, ведь эта страница об уменьшении объёма данных на странице :)). Но вы можете посмотреть итоговые GIFы здесь https://github.com/singhkays/its-time-replace-gifs-with-av1-video/blob/master/GIFs
Примечание переводчика: Хабр не позволяет включить автовоспроизведение и зациклить файл, поэтому оценить получится только качество. Посмотреть как будут выглядеть «анимированные картинки» вживую можно в оригинальной статье.
Сцена 1 @ 200 Kbps
Здесь много движения, что особенно чувствительно на низких битрейтах. Сразу видно, как плох H.264 на этом битрейте сразу видны квадраты. VP9 немного улучшает ситуацию, но квадраты всё ещё видны. AV1 явно выигрывает, выдавая очевидно лучшую картинку.
H.264
VP9
AV1
Сцена 2 @ 200 Kbps
Здесь много полупрозрачного CGI контента. Результаты уже не отличаются так сильно, как в прошлый раз, но в целом AV1 выглядит лучше.
H.264
VP9
AV1
Сцена 3 @ 100 Kbps
В этой сцене, мы выкручиваем битрейт вниз до 100 Kbps и результаты соответствуют. AV1 сохраняет лидерство и на низких битрейтах!
H.264
VP9
AV1
Вишенка на торте
Чтобы закончить статью, ощутив количество сэкономленного трафика по сравнению с GIF — общий размер всех видео выше… 1.62 МБ!! Правильно. Каких-то грёбаных 1,708,032 байт! Для сравнения, вот размер видео GIF и AV1 для каждой из сцен
| GIF | AV1 | |
|---|---|---|
| Сцена 1 | 11.7 MB | 0.33 MB |
| Сцена 2 | 7.27 MB | 0.18 MB |
| Сцена 3 | 5.62 MB | 0.088 MB |
Просто сногсшибательно! Не так ли?
Примечание: Размеры файлов VP9 и H264 не приведены, так как практически не отличаются от AV1 из-за использования того же битрейта. Было бы избыточно добавлять ещё два столбца с одинаковыми размерами, только чтобы подчеркнуть, что эти кодеки выдают гораздо лучшее качество чем GIF при сильно меньших размерах файлов.
Комментарии (60)
andreymal
13.06.2019 22:04Про длительность кодирования тактично умолчим?)
nevzorofff
13.06.2019 22:40-1Серьёзно? Как вижу веб-разработка, так сразу обсуждают многоядерных монстров с 16гб памяти, что мой десктоп на 1055Т с 8гб кажется диким старьём, и тем не менее FullHD видео с регистратор перекодирует за считанные секунды.
andreymal
13.06.2019 22:42+2Хотел бы я быть таким веб-разработчиком...) С момента отправки моего комментария ffmpeg на моём i5-4210U накодировал всего 7 секунд av1-видео
germn Автор
13.06.2019 22:47Вы видео и настройки из статьи используете?
andreymal
13.06.2019 22:53+1Да, скопипастил команды из поста без изменений (кроме имён файлов) — speed=0.00321x :)
Правда, я не обнаружил ссылки на обрезанный оригинал, а обрезать самому лень, так что в качестве оригинала пришлось взять то же самое av1-видео из поста — возможно, это повлияло на чистоту эксперимента, хотя не думаю
ObitoUchiha1985
16.06.2019 01:59Лучше кодировать с помощью rav1e, а потом загонять в mp4 с помощью ffmpeg.
У меня вышло что rav1e кодирует в 5 раз быстрее при чуть лучшем качестве, но я кодировал запись игры в 1080р разрешении.
На моём i5-2520m получилась скорость 0.0026х, если учесть разрешение, то разница довольно большая.
epsonic
14.06.2019 14:27AV1 все еще исключительно процессоро-интенсивный кодек на этапе сжатия материала, и это не новости. Даже после свежих обновлений. Он принципиально организован так, что оптимизировать его с каждым обновлением будет все сложнее и сложнее. С большой долей вероятности он даже через 2-3 года будет требовать на порядок больше времени на сжатие, чем X/H.265 при схожем битрейте и более-менее схожих настройках анализа смены кадров и тщательности расчета векторов движения. Да, на выходе получается просто чудо, а не материал, я сам давно мечтаю в него что-нибудь пожать из архивного. Но не с такой скоростью… Чтобы примерно оценить, насколько он математически более сложен, достаточно оценить стоимость пожатия 1000 минут видео в облаке, например, у qencode:
H.265
dimka11
14.06.2019 17:51В будущем появятся аппаратные решения для кодирования/ декодирования.
Deerenaros
14.06.2019 18:58В будущем, это вы про 10-20 лет говорите? Когда появятся энтропийно оптимальные кодеки и будет активно развиваться квантовое сжатие? Шучу, но частично)
Всё таки даже x264 не кодируется аппаратно так же хорошо, как на CPU: на том же битрейте качество довольно сильно проседает. В будущем AV1 либо заменят на нейросетевые аналоги с теоретическим восстановлением сигнала, что сведёт крайне сложную математику к не менее сложной, но намного более типичной. Ну или же на GPU подвезут тройную точность, во что я правда совершенно не верю с учётом совеременной тенденции к максимальной экономии: скорее мы увидим 4-битовые операции, чем 96 и тем более 128 битовые.
FrytechTV
15.06.2019 15:17Ага, появятся. Сколько там у вас устройств с аппаратной поддержкой VP9, например? И я имею ввиду Encoding, а не Decoding. Сколько контента люди, которые собственно создают контент, могут нормально экспортировать с VP9/AV1 кодеком? А сколько с H.265?
Так-то, на сколько я знаю, ни Nvidia, ни уж тем более AMD не имеют аппаратной поддержки даже VP9 encoder, а это значит, что вместо около-рилтайм экспорта с H265 и NVENC даже на слабеньких картах типа GTX 1060, вы получаете натурально часы ожидания.
А уж если AV1 в 6 тысяч! раз медленнее H264, то о нём нет смысла разговаривать совершенно, до тех пор пока те самые аппаратные решения не появятся. А видя с какой скоростью идёт поддержка даже H265, у меня есть большие сомнения, что AV1 будет какой-бы то ни было альтернативой в ближайшие лет так 5, а то и все 10.khim
15.06.2019 16:47+1Сколько контента люди, которые собственно создают контент, могут нормально экспортировать с VP9/AV1 кодеком? А сколько с H.265?
Собственно «весь» — в обоих случаях. Создание контента — недешёвая процедура.
Если же вы о тех, кто захватывает и пережимает всякие Blu-Ray… ну если у них возникнут проблемы — я не думаю что хоть кто-то из участников консорциума, разрабатывающего AV1 обидится…
А видя с какой скоростью идёт поддержка даже H265, у меня есть большие сомнения, что AV1 будет какой-бы то ни было альтернативой в ближайшие лет так 5, а то и все 10.
Что значит «идёт поддержка даже H265»? Нет этой поддержки — и не будет. Не потому что, что это сложно сделать, а потому что это нафиг никому не надо: продажа железяки с H265-энкодером это такое минное поле из патентов, что никто, кроме, по большому счёту, Apple просто не рискует туда заходить.
AV1, собственно, и начали создавать потому что стало понятно, что H265 никуда не взлетит…FrytechTV
16.06.2019 08:34Собственно «весь» — в обоих случаях. Создание контента — недешёвая процедура.
Эм, мы живём в разных вселенных, судя по всему.
Создание контента уже давно довольно доступная процедура.
Я периодически делаю видео для интернета и иногда экспортирую их с помощью H265, чтобы занимали меньше места на диске. Так вот поддержка H265 встроена не только в большинство видео-редакторов (Resolve, FCPX, Premiere), но и ускоряется посредством GPU очень очень сильно. Почему? Потому что у Nvidia есть встроенный в карту hardware acceleration H265. Не открытый бла-бла что-то за что Google не хочет платить лицензионных отчислений, а H265. Почему это важно? Потому что кодирование 5 минутного видео на CPU занимает около часа на i5 8600K, а на GTX 1060 6GB идёт почти realtime. А время-деньги. Да и вообще как-то не очень интересно сидеть час за компьютером у которого загружены все ядра, а следовательно, вы на нём ничего больше сделать и не можете.
Нет этой поддержки — и не будет.
Нет поддержки H265? Опять же, на какой планете вы живёте? Я вам привёл пример, что ускорение видео на GPU сейчас только и есть для H264/H265, а не открытых кодеков. Почему GPU? Опять же, если GPU может что-то сделать всего за 5-10% времени, то зачем использовать CPU.
ObitoUchiha1985
16.06.2019 01:55На Википедии есть табличка где расписано что поддерживает decoding/encoding VP9.
Новые интелы могут кодировать в VP9.
Даже некоторые мобильные процессоры поддерживают encoding VP9.FrytechTV
16.06.2019 08:36То, что на словах в Intel встроена поддержка VP9 не означает, что вы легко можете ей воспользоваться. И уж поверьте, никто профессионально занимающийся видео не станет писать код, собирать билды, и делать кучу манипуляций только для того, чтобы использовать VP8/9. Если поддержки этого добра нет в софте (даже не говоря про железное ускорение) – для видео индустрии этого, считай, не существует.
ObitoUchiha1985
16.06.2019 10:49А при чём тут программы то? Просто разработчики не добавили в свои программы экспорт VP9 и всё. Возможно и не добавят никогда, только на аппаратную поддержку это никак не влияет.
И если вы не знаете, Nvidia и Intel руководящие члены aom, значит они участвуют в разработке av1, значит аппаратная поддержка может появиться быстрее чем у того же H265.
Дополнение
Я даже не знаю зачем делать экспорт сразу в h264 или h265, если можно сделать экспорт в кодек без потерь и потом нормально закодировать.
С моими видосами выходило что premier pro экспортирует в h264 с качеством примерно как у x264 veryfast, но при этом делает это в 2 раза медленнее.
Соответственно смысла экспортировать в h264 нет никакого.
H265 я даже не смотрел так-как premier pro экспортирует в него очень долго по сравнению с x265.
А NVENC он конечно хорош, но только когда нет ограничений по битрейту и можно спокойно поставить битрейт на 20-30% выше.FrytechTV
16.06.2019 20:12А при чём тут программы то? Просто разработчики не добавили…
А видео вы как редактируете? Прямо на железе? Не всё так «просто».
И если вы не знаете…
Знаю, только это во-первых ни о чём не говорит, а во-вторых, поскольку это всё ещё только в разработке, а проекты делать надо сейчас, то это не имеет никакого значения в данное время.
Я даже не знаю зачем делать экспорт сразу в h264 или h265, если можно сделать экспорт в кодек без потерь и потом нормально закодировать.…
А зачем мне дурную работу делать? Если я могу экспортировать проект сразу, зачем мне сначала создавать файл гигов на 30, а потом его кодировать ещё раз?
В H265 иногда приходится экспортировать, потому что на том же Vimeo есть недельные лимиты на количество гигабайт, которые можно туда загрузить. Если я могу ужать видео и таким образом не упереться в эти самые лимиты, то почему бы этого и не сделать?
premier pro экспортирует в него очень долго
А теперь представьте, что ваше очень «долго» будет длится в несколько тысяч! раз дольше. Если к моменту релиза ничего с этим конкретным моментом не исправится в лучшую сторону, и если Nvidia/AMD не встроят hardware AV1 encoder, то всё это будет очень печально.ObitoUchiha1985
16.06.2019 20:59Если к моменту релиза
А к моменту какого релиза? Релиз AV1 был больше года назад. Какой ещё релиз будет?
зачем мне сначала создавать файл гигов на 30, а потом его кодировать ещё раз?
Чтобы сильнее сжать, сами же говорите про лимиты на vimeo.
А теперь представьте, что ваше очень «долго» будет длится в несколько тысяч! раз дольше
Не в несколько тысяч раз! В коментарии ниже написано что в 658.5 раз дольше чем VP9.
Ну и к тому же не обязательно использовать libaom, есть rav1e который кодирует в 5-8 раз быстрее. Вот и выходит что дольше всего в 130-82 раза. А rav1e сейчас только версии 0.1, возможно он станет ещё в 2-4 раза быстрее к версии 1.0
Если поддержки этого добра нет в софте (даже не говоря про железное ускорение) – для видео индустрии этого, считай, не существует.
Что-то гуглу это никак не мешает. Конечно если вы выкладываете видео на ютуб, vimeo или ещё куда-то, то вам в принципе фиолетово какой кодек использовать(а ютубу пофиг даже на битрейт видео). А если у вас свой сайт и вы оплачиваете трафик, то сожмёте даже если это в 100 раз дольше.
SuAlUr
14.06.2019 14:37По ссылке из поста — «On the other hand, the encoding computational complexity (in terms of encoding run time) of AV1 compared with x264 main, x264 high and libvpx-vp9 for CRF/QP mode was increased by factors of 5721.5x, 5869.9x and 658.5x, respectively, as shown in Figure 4».
Действительно, всего-то в 5870 раз медленнее x264.
TheGodfather
13.06.2019 22:08+1Меньше 300 килобайт на 11-секундное видео с активными сценами — вау! Я немного динозавр и, наверное, отстал от жизни, но последняя табличка на самом деле очень удивляет, абсолютно не ожидал такого!
P.S. Хотя в моем динозавровом мире GIF используется для простенькой анимации, читай — анимированные смайлики или просто баннеры, вставлять в таких случаях видео — какой-то неадекват, имхо. Но для всяких новомодных «лендингов» с большим видео в топе, наверное, имеет смысл.
Aingis
13.06.2019 23:03+1Недостатки есть: кодек заметно грузит процессор. Это значит, что видео будет тормозить на слабых устройствах и сильнее есть батарею. Так что прожорливый Хром с WebM на Ютюбе покажется верхом экономности.
Labunsky
13.06.2019 22:24+1Заменяем сжатые без потерь изображения на lossy-видео и радуемся. Мне кажется, изначально проблема изначально не столько в бедном формате, сколько в его применении
khim
14.06.2019 05:23+1С каких пор GIF стал «сжатием без потерь»?
Там на одной необходимости загнать картинку в 256 цветов потерь больше, чем от любого, самого ужасного, видеокодека.Aingis
14.06.2019 11:22Вообще-то есть способ обойти это ограничение. Хотя конечно формат gif подходит для этого хуже всего.
Labunsky
14.06.2019 14:08-1Всегда был. Количество цветов — это не потери, сами значения кодируются LZW. Просто во времена его создания (а это 87й год, на секунду) не знали, что кому-то потребуется больше)
khim
14.06.2019 14:48Анимированный GIF — это 89й. Это во-первых. А во-вторых тот факт, что существуют анимации, которые сохраняют качество при конвертации в GIF не делает это преобразование сжатием без потерь. Чёрный квадрат Малевича в любом виде будет чёрным.
Сжатие же реального, существующего, источника — теряет информацию. Причём много. И даже GifSki лишь уменьшает эти потери.
То, что изначально рисовалось в 16-64-256 цветах (смайлики, например) — можно в GIF и оставить… Там это уместно вполне.Labunsky
14.06.2019 15:21Простите мне мою неученость и ошибку на целых два года. Прошу не казнить, а помиловать :(
То, что люди тру колор в гифки запихивают, является проблемой не формата, а людей. Сама же спецификация описывает кодирование 256-цветных изображений без потерь, определение вида сжатия строгое и не подлежит обсуждению. Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть "без потерь"
khim
14.06.2019 17:52Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть «без потерь»
Не окажется. В PNG изначально предусмотрен 64-битный формат (16 бит RGB плюс альфа-канал).Labunsky
14.06.2019 18:19Что, правда? Не знал. Ну окей, тогда через еще большее число лет при использовании N-битного цвета, где N > 64, суть особо не меняется
khim
14.06.2019 18:23Ну вот когда (и если) в PNG будут перекодировать (с дизерингом) картинки какие-нибудь клингоняне с четырьмя видами рецепторов в глазу — его использование тоже перестанет быть «сжатыми без потерь изображениями».
Labunsky
14.06.2019 19:18Да не перестанет. Сама спецификация не ущемляет цветовую палитру, она просто не знает, что существует другая. А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметны
khim
14.06.2019 19:58Ой какие слова вумные. «Спецификации», «алгоритмы» и всё такое прочее. Вот где они в исходном высказывании? Извините — вы там чётко заявляли про переход от «сжатых без потерь изображений» (типа хорошо) на «lossy-видео» (типа плохо).
Однако же: вы можете разводить любую демагогию на тему «алгоритмов» и «спецификаций», но от этого GIF-артефакты с КДПВ этой статьи никуда не пропадут. А раз артефакты имеются — то это уже не «сжатые без потерь изображения», извините.
И да — спецификация предусматривает наличие в палитре 256 цветов. Чего для тех изображений, которые мы хотим показывать — не хватает…
А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметны
Ну если это JPEG2000 — то вполне. Но речь не об этом. Речь о том, что в вашем исходном сообщении вы не говорить про «алгоритмы» и «форматы». И потому оно является враньём.
И я даже понимаю почему: если бы вы туда втащили «алгоритмы» и «форматы» (перешли от формата, сжимающего без потерь к форматам, сжимающим с форматами) — то эмоциональный эффект был бы утерян: ну да, был формат, теоретически, без потерь, теперь, теоретически, с потерями… ну и что? Картинка-то объективно стала меньше артефактов содержать…Labunsky
14.06.2019 20:58-1Чего для тех изображений, которые мы хотим показывать — не хватает…
Ну раз не хватает, то чего формат винить? В том самом первом комментарии (в котором ничего не найти и вообще нипонятна) написал, что проблема в людях, которые зачем-то видео запихивают в гифки. Давайте их же в APNG заводить и говорить, какой он плохой, весит много. И призывать переходить с APNG на AV1 (???)
стала меньше артефактов содержать
Артефакты — это искажения, сделанные кодеком. Так как он у гифок не делает ни одной операции, потенциально приводящей к потере качества (в отличие от этих наших джипегов), то он физически не может привести к их появлению
Говоря проще — сколько бы раз мы гифку не перекодировали, мы на выходе будем получать одно и то же изображение. А какой-нибудь джипег с каждым разом будет деградировать все больше и больше, создавая артефакты, потому что в процессе перевода сырого изображения в сжатую форму совершаются те самые операции с потерей данных
Определения видов сжатий были придуманы не мной и не сегодня, зачем с ними спорить?
ObitoUchiha1985
14.06.2019 13:57Тоже так подумал.
Хорошо если есть исходник, тогда качество будет лучше, но сжимать гиф в видео вообще плохая затея.
А гиф с дезирингом видеокодек вообще нормально не сожмёт.
AngReload
14.06.2019 16:24При желании dither-инг можно убрать undither-ингом. Изображение становится ближе к исходному, и лучше сжимается в видео.
mistergrim
13.06.2019 23:03+1Ну а если у пользователя совсем старый девайс или навигатор, который видео не поддерживает вообще (что крайте маловероятно с H264), то он просто увидит GIF
Вот бы кто подсказал, как с современными девайсами так сделать. А то уже выбешивают сайты, которые под видом GIF отдают MP4.
NeoCode
14.06.2019 07:07Для картинок (и gif в том числе) во всех браузерах есть встроенная в контекстное меню команда «Сохранить». Для видео почему-то нет. То есть конечно можно поставить какой нибудь плагин к браузеру (но они не всегда корректно работают). Но по умолчанию — нет.
Лично мне очень не нравится, когда у меня отнимают возможность свободно делать с контентом что угодно — в первую очередь сохранять себе на диск.
GennPen
14.06.2019 08:57Firefox 67 без дополнений, есть сохранить видео, и текущий кадр.
Да и в любом случае можно глянуть исходник в HTML и скачать видео по ссылке.
Заголовок спойлера
epsonic
14.06.2019 14:37Возможно, автор комментария пытался скачать потоковый материал, который со стороны выглядит как обычное видео в нативном плеере браузера, но на самом деле представляет собой HLS-стрим или MPEG-DASH-стрим из кусков, которые грузятся один за другим согласно плейлисту. Для таких опция «скачать видео» недоступна. Попробуйте, например, дважды кликнуть правой кнопкой по видео на YouTube.
epsonic
14.06.2019 14:47Тут проблема двоякая: если все видео выкладывать в виде одного большого «streamable»-файла, то его, во-первых, может с легкостью скачать любой желающий, и, во-вторых, он будет просто безжалостен к трафику, ибо весь, скажем, фильм размером в гигабайт и более будет сразу скачиваться от начала и до конца при запросе (если только браузер не достаточно «умен», чтобы приостанавливать загрузку далее текущего положения ползунка в плеере).
Чтобы это исправить используют т.н. HTTP Live Streaming. Плюсы: видео заранее порезано на части по несколько секунд (причем в разных качествах для разных сетей — от быстрых, до очень медленных), которые передаются браузеру в виде плейлиста со ссылками на все куски. Клиент может быстро переходить к нужному участку видео, получить возможность выбора дополнительных аудиодорожек, которые реализованы таким же образом, экономит трафик, поставив видео на паузу (грузится, скажем, 30 секунд, после чего буферизация новых «кусков» прекращается) и еще много плюсов как для мобильных клиентов, так и для соседей по дому, которые так же хотят смотреть стримы на твиче и видео в YouTube. Но минус такого решения, конечно, в том, что чтобы скачать такое видео, нужно выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg. Однако к большинству браузеров существует туча плагинов, которые умеют перехватывать HLS-трафик, к примеру, и сшивать видео в один файл на диске.
ivan386
14.06.2019 20:19выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg
Достаточно дать ffmpeg ссылочку на плейлист и он сам скачает и склеет.
Вроде так:
ffmpeg -i https://example.org/stream.m3u8 -c copy out.mkv
Taraflex
14.06.2019 15:05Картинка всегда единый файл (да и тот же канвас всегда можно сжать из памяти «по месту»).
Современное же видео это, кроме псевдо стриминга из обычного mp4 файла еще и
DASH
HLS
WEBRTS
Которые не получиться просто взять и сохранить в файл.
upd: нужно приучить себя обновлять страницу перед отправкой комментария — выше ответили более развернуто.
nfw
14.06.2019 08:17На Вивальди все есть
copyhold
14.06.2019 11:31Lighthouse радуется когда видит видео вместо гифов, и справедливо — разница действительно значительная. При замене гифов на видео я стандартно получал из 1.5М — 300К.
Единственная большая проблема это прозрачность. VP9(8) не работают в Сафари, к сожалению ( а айфон — наше всё ). Это решается только хитрым методом
diafour
14.06.2019 15:43Там, куда мы направляемся, нам не понадобятся GIFы!
Github давно зовут, но к сожалению пока не идёт что-то. :(
guryanov
14.06.2019 15:47Очень круто! Вообще поражает скорость разработки и принятия решений во многих проектах сейчас.
redf1sh
14.06.2019 23:52+1Меня интересует вопрос: если я могу сейчас с условного сайта скачать GIFку и легко прикрепить на другом сайте или отправить в вк, то что делать с этим видео? Как будут реализованы такие возможности? Потому что на сайтах которые заменяют гифки на видео это превращается в гемморой
KvanTTT
15.06.2019 02:50В жизни большинство вещей имеют свои плюсы и минусы. Когда вы заменяете GIF на видео, минусов чаще всего найти не получится.
К чему было это писать, если в комментариях расписали предостаточно минусов:
- Очень медленное кодирование.
- Отсутствие аппаратной и даже программной поддержки.
- Видео нельзя просто сохранить или копировать.
andreymal
15.06.2019 12:21Обратите внимание, что в процитированном предложении говорится про видео в целом, а не конкретно про AV1.
- H.264 легко кодируется в реалтайме, libx264 достаточно оптимизирован.
- Аппаратная поддержка H.264 встроена чуть ли не в каждую кофеварку.
- В любом нормальном браузере есть пункт меню про сохранение видеофайла.
pereyaslavskiy
15.06.2019 15:18Сейчас бы в 2019 говорить о методах, которые толком смартфонами не поддерживаются. При том, что доля смартфонов выше доли десктопов во многих сферах.
А еще мобильные браузеры идут к тому чтобы выключить автовоспроизведение даже для видео без звука…
mastiff
15.06.2019 15:18Как веб-разработчик, вы хотите минимизировать вещи, которые пользователям нужно скачать, чтобы сайт загружался быстро. По той же причине вы минимизируете JavaScript, оптимизируйте PNG, JPEG, а иногда и конвертируете JPEG в WebP
Судя по большиству сайтов в интернетах веб-разработчики делают строго противоположное…
perfect_genius
16.06.2019 21:342025 год, видео окончательно заменила GIF.
На Хабре продолжают выкладывать 4к-фотографии в PNG.
perfect_genius
16.06.2019 21:40Кто-нибудь знает как создавать ВКонтакте гифки, которые проигрываются сами и почему такое есть? Я коллекционирую такие, они грузятся-выкладываются под видом PNG, но изучить причину пока нет возможности. Пересохранение такой картинки портит возможность обманывать эту соцсесть.
decomeron
Почему-то на огрызке ни VP9 ни AV1 не показывает. И браузер вроде обновлен
germn Автор
Полез смотреть, похоже не поддерживается =\
Там же пишут о возможных причинах:
А HEVC это упомянутый в статье H.265
Ну, в принципе, можно и в H.265 дополнительно кодировать по той же схеме, которая показана в статье. Но актуально это будет, вероятно, только для яблока.
shifttstas
Samsung так же за HEVC
germn Автор
Однако, как минимум точно не против AV1.
bopoh13
Android 8.1 не открывает.
navion
AV1 добавили в десятом Андроиде.