Пришло время заменить GIF на AV1 видео

Автор оригинала: Kay Singh
  • Перевод


Сейчас 2019 год, и нам пора бы принять решение относительно GIF (нет, речь не об этом решении! Здесь мы никогда не договоримся! — тут речь о произношении в английском, для нас это не актуально — прим. перев.). GIFы занимают огромное количество места (обычно по несколько мегабайт!) что, если вы веб-разработчик, полностью противоречит вашим желаниям! Как веб-разработчик, вы хотите минимизировать вещи, которые пользователям нужно скачать, чтобы сайт загружался быстро. По той же причине вы минимизируете JavaScript, оптимизируете PNG, JPEG, а иногда и конвертируете JPEG в WebP. Но что же делать со старичком GIFом?


Там, куда мы направляемся, нам не понадобятся GIFы!


Если ваша цель — улучшить скорость загрузки сайта, то от GIF нужно избавляться! Но как же тогда делать анимированные картинки? Ответ — видео. И в большинстве случаев, вы получите лучшее качество и экономию места в 50-90%! В жизни большинство вещей имеют свои плюсы и минусы. Когда вы заменяете GIF на видео, минусов чаще всего найти не получится.


Долой все GIFы!


К счастью, замена GIF на видео была обычным делом последние годы, так что все необходимые инструменты уже в ходу. В этом посте, я не стану изобретать велосипед, а лишь немного улучшу имеющиеся решения. Итак, вот суть:


  1. Возьмите GIF и переконвертируйте его в видео
  2. Закодируйте видео с помощью H.264 или VP9, т.е. сожмите его и упакуйте в MP4 или WebM контейнер
  3. Замените <img> с анимированным GIF на <video> с роликом
  4. Включите автовоспроизведение без звука и зациклите, чтобы добиться эффекта GIF

У Google есть хорошая документация, описывающая процесс.


Сейчас 2019 год


Сейчас 2019 год. Прогресс движется вперёд, а мы должны от него не отставать. До сих пор у нас было два варианта кодеков, которые широко поддерживаются во всех браузерах и инструментах для кодирования видео:


  1. H.264 — появившийся в 2003 и шире всего используемый сегодня
  2. 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 при сильно меньших размерах файлов.

Поддержать автора
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 71

    +2

    Почему-то на огрызке ни VP9 ни AV1 не показывает. И браузер вроде обновлен

      0
      Полез смотреть, похоже не поддерживается =\

      Там же пишут о возможных причинах:
      Hence they didn't support VP9 to push everyone to HEVC, so they make money from HEVC licensing

      А HEVC это упомянутый в статье H.265

      Ну, в принципе, можно и в H.265 дополнительно кодировать по той же схеме, которая показана в статье. Но актуально это будет, вероятно, только для яблока.
        +1

        Samsung так же за HEVC

        0
        Android 8.1 не открывает.
          +1

          AV1 добавили в десятом Андроиде.

      0

      Про длительность кодирования тактично умолчим?)

        –1
        Серьёзно? Как вижу веб-разработка, так сразу обсуждают многоядерных монстров с 16гб памяти, что мой десктоп на 1055Т с 8гб кажется диким старьём, и тем не менее FullHD видео с регистратор перекодирует за считанные секунды.
          +3

          Хотел бы я быть таким веб-разработчиком...) С момента отправки моего комментария ffmpeg на моём i5-4210U накодировал всего 7 секунд av1-видео

            0
            Вы видео и настройки из статьи используете?
              +1

              Да, скопипастил команды из поста без изменений (кроме имён файлов) — speed=0.00321x :)


              Правда, я не обнаружил ссылки на обрезанный оригинал, а обрезать самому лень, так что в качестве оригинала пришлось взять то же самое av1-видео из поста — возможно, это повлияло на чистоту эксперимента, хотя не думаю

                0
                Лучше кодировать с помощью rav1e, а потом загонять в mp4 с помощью ffmpeg.
                У меня вышло что rav1e кодирует в 5 раз быстрее при чуть лучшем качестве, но я кодировал запись игры в 1080р разрешении.
                На моём i5-2520m получилась скорость 0.0026х, если учесть разрешение, то разница довольно большая.
                +3
                AV1 все еще исключительно процессоро-интенсивный кодек на этапе сжатия материала, и это не новости. Даже после свежих обновлений. Он принципиально организован так, что оптимизировать его с каждым обновлением будет все сложнее и сложнее. С большой долей вероятности он даже через 2-3 года будет требовать на порядок больше времени на сжатие, чем X/H.265 при схожем битрейте и более-менее схожих настройках анализа смены кадров и тщательности расчета векторов движения. Да, на выходе получается просто чудо, а не материал, я сам давно мечтаю в него что-нибудь пожать из архивного. Но не с такой скоростью… Чтобы примерно оценить, насколько он математически более сложен, достаточно оценить стоимость пожатия 1000 минут видео в облаке, например, у qencode:

                H.265


                AV1

                  0

                  В будущем появятся аппаратные решения для кодирования/ декодирования.

                    +1

                    В будущем, это вы про 10-20 лет говорите? Когда появятся энтропийно оптимальные кодеки и будет активно развиваться квантовое сжатие? Шучу, но частично)


                    Всё таки даже x264 не кодируется аппаратно так же хорошо, как на CPU: на том же битрейте качество довольно сильно проседает. В будущем AV1 либо заменят на нейросетевые аналоги с теоретическим восстановлением сигнала, что сведёт крайне сложную математику к не менее сложной, но намного более типичной. Ну или же на GPU подвезут тройную точность, во что я правда совершенно не верю с учётом совеременной тенденции к максимальной экономии: скорее мы увидим 4-битовые операции, чем 96 и тем более 128 битовые.

                      +2
                      Ага, появятся. Сколько там у вас устройств с аппаратной поддержкой VP9, например? И я имею ввиду Encoding, а не Decoding. Сколько контента люди, которые собственно создают контент, могут нормально экспортировать с VP9/AV1 кодеком? А сколько с H.265?

                      Так-то, на сколько я знаю, ни Nvidia, ни уж тем более AMD не имеют аппаратной поддержки даже VP9 encoder, а это значит, что вместо около-рилтайм экспорта с H265 и NVENC даже на слабеньких картах типа GTX 1060, вы получаете натурально часы ожидания.

                      А уж если AV1 в 6 тысяч! раз медленнее H264, то о нём нет смысла разговаривать совершенно, до тех пор пока те самые аппаратные решения не появятся. А видя с какой скоростью идёт поддержка даже H265, у меня есть большие сомнения, что AV1 будет какой-бы то ни было альтернативой в ближайшие лет так 5, а то и все 10.
                        –1
                        Сколько контента люди, которые собственно создают контент, могут нормально экспортировать с VP9/AV1 кодеком? А сколько с H.265?
                        Собственно «весь» — в обоих случаях. Создание контента — недешёвая процедура.

                        Если же вы о тех, кто захватывает и пережимает всякие Blu-Ray… ну если у них возникнут проблемы — я не думаю что хоть кто-то из участников консорциума, разрабатывающего AV1 обидится…

                        А видя с какой скоростью идёт поддержка даже H265, у меня есть большие сомнения, что AV1 будет какой-бы то ни было альтернативой в ближайшие лет так 5, а то и все 10.
                        Что значит «идёт поддержка даже H265»? Нет этой поддержки — и не будет. Не потому что, что это сложно сделать, а потому что это нафиг никому не надо: продажа железяки с H265-энкодером это такое минное поле из патентов, что никто, кроме, по большому счёту, Apple просто не рискует туда заходить.

                        AV1, собственно, и начали создавать потому что стало понятно, что H265 никуда не взлетит…
                          +3
                          Собственно «весь» — в обоих случаях. Создание контента — недешёвая процедура.
                          Эм, мы живём в разных вселенных, судя по всему.
                          Создание контента уже давно довольно доступная процедура.
                          Я периодически делаю видео для интернета и иногда экспортирую их с помощью 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.
                          0
                          На Википедии есть табличка где расписано что поддерживает decoding/encoding VP9.
                          Новые интелы могут кодировать в VP9.
                          Даже некоторые мобильные процессоры поддерживают encoding VP9.
                            0
                            То, что на словах в Intel встроена поддержка VP9 не означает, что вы легко можете ей воспользоваться. И уж поверьте, никто профессионально занимающийся видео не станет писать код, собирать билды, и делать кучу манипуляций только для того, чтобы использовать VP8/9. Если поддержки этого добра нет в софте (даже не говоря про железное ускорение) – для видео индустрии этого, считай, не существует.
                              0
                              А при чём тут программы то? Просто разработчики не добавили в свои программы экспорт VP9 и всё. Возможно и не добавят никогда, только на аппаратную поддержку это никак не влияет.
                              И если вы не знаете, Nvidia и Intel руководящие члены aom, значит они участвуют в разработке av1, значит аппаратная поддержка может появиться быстрее чем у того же H265.

                              Дополнение
                              Я даже не знаю зачем делать экспорт сразу в h264 или h265, если можно сделать экспорт в кодек без потерь и потом нормально закодировать.
                              С моими видосами выходило что premier pro экспортирует в h264 с качеством примерно как у x264 veryfast, но при этом делает это в 2 раза медленнее.
                              Соответственно смысла экспортировать в h264 нет никакого.
                              H265 я даже не смотрел так-как premier pro экспортирует в него очень долго по сравнению с x265.
                              А NVENC он конечно хорош, но только когда нет ограничений по битрейту и можно спокойно поставить битрейт на 20-30% выше.
                                0
                                А при чём тут программы то? Просто разработчики не добавили…
                                А видео вы как редактируете? Прямо на железе? Не всё так «просто».
                                И если вы не знаете…
                                Знаю, только это во-первых ни о чём не говорит, а во-вторых, поскольку это всё ещё только в разработке, а проекты делать надо сейчас, то это не имеет никакого значения в данное время.
                                Я даже не знаю зачем делать экспорт сразу в h264 или h265, если можно сделать экспорт в кодек без потерь и потом нормально закодировать.…
                                А зачем мне дурную работу делать? Если я могу экспортировать проект сразу, зачем мне сначала создавать файл гигов на 30, а потом его кодировать ещё раз?
                                В H265 иногда приходится экспортировать, потому что на том же Vimeo есть недельные лимиты на количество гигабайт, которые можно туда загрузить. Если я могу ужать видео и таким образом не упереться в эти самые лимиты, то почему бы этого и не сделать?
                                premier pro экспортирует в него очень долго
                                А теперь представьте, что ваше очень «долго» будет длится в несколько тысяч! раз дольше. Если к моменту релиза ничего с этим конкретным моментом не исправится в лучшую сторону, и если Nvidia/AMD не встроят hardware AV1 encoder, то всё это будет очень печально.
                                  –1
                                  Если к моменту релиза
                                  А к моменту какого релиза? Релиз AV1 был больше года назад. Какой ещё релиз будет?
                                  зачем мне сначала создавать файл гигов на 30, а потом его кодировать ещё раз?
                                  Чтобы сильнее сжать, сами же говорите про лимиты на vimeo.
                                  А теперь представьте, что ваше очень «долго» будет длится в несколько тысяч! раз дольше
                                  Не в несколько тысяч раз! В коментарии ниже написано что в 658.5 раз дольше чем VP9.
                                  Ну и к тому же не обязательно использовать libaom, есть rav1e который кодирует в 5-8 раз быстрее. Вот и выходит что дольше всего в 130-82 раза. А rav1e сейчас только версии 0.1, возможно он станет ещё в 2-4 раза быстрее к версии 1.0
                                  Если поддержки этого добра нет в софте (даже не говоря про железное ускорение) – для видео индустрии этого, считай, не существует.
                                  Что-то гуглу это никак не мешает. Конечно если вы выкладываете видео на ютуб, vimeo или ещё куда-то, то вам в принципе фиолетово какой кодек использовать(а ютубу пофиг даже на битрейт видео). А если у вас свой сайт и вы оплачиваете трафик, то сожмёте даже если это в 100 раз дольше.
                                    +1
                                    Что бывает, когда (предположительно) программист разговаривает о видео…

                                    Я повторюсь, в среде тех, кто делает видео контент, или его монтирует, никто не станет использовать никакие libaom, rav1e или что-то ещё с труднопроизносимыми названиями, что вызывается командой из терминала.
                                    Если нет поддержки в софте в первую очередь, и в железе во вторую, считайте, что этого не существует. Вы мне можете не верить, конечно, но это реальность.

                                    Видео с камер RED очень долгое время было слишком тяжёлым для воспроизведения даже на довольно мощных CPU, поэтому RED продавали ускоритель RED Rocket X, который стоил баснословных денег, учитывая, что всё что он делает, это занимается декодированием и дебайрингом. А потом они внезапно осознали, что GPU может делать тоже самое, и решили скооперироваться с Nvidia, чтобы делать ту же процедуру не на специальной карте, стоимостью почти $7K, а на обычных GPU. К чему я это? К тому, что все пытаются ускорить workflow, а не замедлить его в 100 – нескольких тысяч раз.

                                    Даже если принять все допущения, в вашем варианте кодирование будет медленнее в ~100 раз чем уже довольно медленное, ничем аппаратным не ускоренное, кодирование VP9. В 100 раз. То есть 10-минутное видео, например, вместо 10 минут экспорта, будет занимать 16 часов. 16 часов вместо 10 минут! Кто в здравом уме будет такое делать? И это, заметьте, в самом лучшем вашем случае. И даже если по вашим словам магическим образом эта процедура станет быстрее ещё в четыре раза, это всё равно будет 10 минут против 4 часов! За довольно сомнительный выигрыш в качестве/размере по сравнению со временем, затраченным на экспорт такого файла.

                                    Вы просто представьте, другой пример: вот вы заливаете видео на ютуб, скажем, а они теперь решили этот ваш новомодный кодек использовать, и теперь ваше видео вместо того, чтобы быть доступно спустя минут 10 после того, как вы его залили, будет доступно, снова же, часов через 5-10. А если речь идёт про что-то важное? Breaking news и т.д.? Стоит оно того?

                                    Вы поверьте, мне тоже нравятся открытые форматы и стандарты, но когда открытость идёт в разрез с производительностью, да ещё в таких пропорциях, это не имеет никакого смысла.
                                      0
                                      Я повторюсь, в среде тех, кто делает видео контент, или его монтирует
                                      Так то кодек и не для них делался. Этот кодек первоначально для потокового видео, а уже потом остальных до которых он дойдёт как только появятся аппаратные реализации.
                                      никто не станет использовать никакие libaom, rav1e или что-то ещё с труднопроизносимыми названиями, что вызывается командой из терминала
                                      А я считаю, что если человек может написать сайт, то разобраться с несколькими командами не составит труда. Ведь в статье ни слова не говорится про вашу среду «тех кто делает контент или монтирует». Статья для разработчиков сайтов.
                                      Если нет поддержки в софте в первую очередь
                                      Так это и есть софт, да это не софт для монтажа, но всё равно же софт.
                                      в вашем варианте кодирование будет медленнее в ~100 раз чем уже довольно медленное
                                      Я как-то совсем забыл про STV-AV1 от интела. Я сам не тестировал так-как нет подходящего процессора, но он может кодировать со скоростью 5.7 кадров в секуду на i9 9900k это уже сейчас примерно в 8 раз быстрее чем rav1e и примерно в 13 раз медленнее чем vp9.
                                      Кто в здравом уме будет такое делать?
                                      Да хотя бы тот же гугл. Он же как-то перешёл на VP9 который в ~10 раз медленнее чем h264. И сейчас так же начал переходить на av1.
                                      вот вы заливаете видео на ютуб, скажем, а они теперь решили этот ваш новомодный кодек использовать
                                      Вот только они уже несколько месяцев используют этот кодек, правда пока максимум в 720р, но всё равно. И это никак не повлияло на скорость появления видео на ютубе. Просто av1 появляется через несколько дней, а до этого используется h264 и vp9. Можете зайти на эту страницу и принудительно включить его. Но сейчас в av1 в основном видео с самыми большими числами просмотров.
                                      Стоит оно того?
                                      Раз гугл использует сразу 3 кодека, то думаю считает что это стоит того.
                                      когда открытость идёт в разрез с производительностью, да ещё в таких пропорциях, это не имеет никакого смысла
                                      А что бы изменилось если бы кодек был проприетарный? Тогда он вообще был бы не нужен никому. Если вам нужно быстро, то для вас уже сейчас существуют h264 и h265 с аппаратными реализациями. Те кому это нужно, будут кодировать в av1. В любом случае наличие этого кодека лучше чем его отсутствие.
                                  0
                                  Nvidia и Intel руководящие члены aom, значит они участвуют в разработке av1, значит аппаратная поддержка может появиться быстрее чем у того же H265.

                                  Интел обещает декодер только к концу 2020 года (в Gen 12 / Xe), а про энкодер пока даже не заикаются.
                                    0
                                    Ну значит в gen 13 будет энкодер, но будет ли в нём смысл не известно(он запросто может выдавать качество не лучше чем сейчас у HEVC(h265)).
                                    Но у интела уже сейчас есть программный энкодер, который быстрее других, но конечно нужно смотреть что там по качеству.
                  +2
                  По ссылке из поста — «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.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  +3
                  Меньше 300 килобайт на 11-секундное видео с активными сценами — вау! Я немного динозавр и, наверное, отстал от жизни, но последняя табличка на самом деле очень удивляет, абсолютно не ожидал такого!

                  P.S. Хотя в моем динозавровом мире GIF используется для простенькой анимации, читай — анимированные смайлики или просто баннеры, вставлять в таких случаях видео — какой-то неадекват, имхо. Но для всяких новомодных «лендингов» с большим видео в топе, наверное, имеет смысл.
                    +1

                    Недостатки есть: кодек заметно грузит процессор. Это значит, что видео будет тормозить на слабых устройствах и сильнее есть батарею. Так что прожорливый Хром с WebM на Ютюбе покажется верхом экономности.

                    +1

                    Заменяем сжатые без потерь изображения на lossy-видео и радуемся. Мне кажется, изначально проблема изначально не столько в бедном формате, сколько в его применении

                      +7
                      С каких пор GIF стал «сжатием без потерь»?

                      Там на одной необходимости загнать картинку в 256 цветов потерь больше, чем от любого, самого ужасного, видеокодека.
                        +3

                        Вообще-то есть способ обойти это ограничение. Хотя конечно формат gif подходит для этого хуже всего.

                          +1

                          Всегда был. Количество цветов — это не потери, сами значения кодируются LZW. Просто во времена его создания (а это 87й год, на секунду) не знали, что кому-то потребуется больше)

                            0
                            Анимированный GIF — это 89й. Это во-первых. А во-вторых тот факт, что существуют анимации, которые сохраняют качество при конвертации в GIF не делает это преобразование сжатием без потерь. Чёрный квадрат Малевича в любом виде будет чёрным.

                            Сжатие же реального, существующего, источника — теряет информацию. Причём много. И даже GifSki лишь уменьшает эти потери.

                            То, что изначально рисовалось в 16-64-256 цветах (смайлики, например) — можно в GIF и оставить… Там это уместно вполне.
                              +2

                              Простите мне мою неученость и ошибку на целых два года. Прошу не казнить, а помиловать :(


                              То, что люди тру колор в гифки запихивают, является проблемой не формата, а людей. Сама же спецификация описывает кодирование 256-цветных изображений без потерь, определение вида сжатия строгое и не подлежит обсуждению. Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть "без потерь"

                                0
                                Иначе спустя несколько лет окажется, что и PNG данные теряет, потому что 64-битный цвет в него не запихнуть «без потерь»
                                Не окажется. В PNG изначально предусмотрен 64-битный формат (16 бит RGB плюс альфа-канал).
                                  0

                                  Что, правда? Не знал. Ну окей, тогда через еще большее число лет при использовании N-битного цвета, где N > 64, суть особо не меняется

                                    0
                                    Ну вот когда (и если) в PNG будут перекодировать (с дизерингом) картинки какие-нибудь клингоняне с четырьмя видами рецепторов в глазу — его использование тоже перестанет быть «сжатыми без потерь изображениями».
                                      0

                                      Да не перестанет. Сама спецификация не ущемляет цветовую палитру, она просто не знает, что существует другая. А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметны

                                        0
                                        Ой какие слова вумные. «Спецификации», «алгоритмы» и всё такое прочее. Вот где они в исходном высказывании? Извините — вы там чётко заявляли про переход от «сжатых без потерь изображений» (типа хорошо) на «lossy-видео» (типа плохо).

                                        Однако же: вы можете разводить любую демагогию на тему «алгоритмов» и «спецификаций», но от этого GIF-артефакты с КДПВ этой статьи никуда не пропадут. А раз артефакты имеются — то это уже не «сжатые без потерь изображения», извините.

                                        И да — спецификация предусматривает наличие в палитре 256 цветов. Чего для тех изображений, которые мы хотим показывать — не хватает…

                                        А то так можно и JPEG назвать алгоритмом со сжатием без потерь, потому что на глаз с хорошей таблицей квантования и большим разрешением потери не заметны
                                        Ну если это JPEG2000 — то вполне. Но речь не об этом. Речь о том, что в вашем исходном сообщении вы не говорить про «алгоритмы» и «форматы». И потому оно является враньём.

                                        И я даже понимаю почему: если бы вы туда втащили «алгоритмы» и «форматы» (перешли от формата, сжимающего без потерь к форматам, сжимающим с форматами) — то эмоциональный эффект был бы утерян: ну да, был формат, теоретически, без потерь, теперь, теоретически, с потерями… ну и что? Картинка-то объективно стала меньше артефактов содержать…
                                          –1
                                          Чего для тех изображений, которые мы хотим показывать — не хватает…

                                          Ну раз не хватает, то чего формат винить? В том самом первом комментарии (в котором ничего не найти и вообще нипонятна) написал, что проблема в людях, которые зачем-то видео запихивают в гифки. Давайте их же в APNG заводить и говорить, какой он плохой, весит много. И призывать переходить с APNG на AV1 (???)


                                          стала меньше артефактов содержать

                                          Артефакты — это искажения, сделанные кодеком. Так как он у гифок не делает ни одной операции, потенциально приводящей к потере качества (в отличие от этих наших джипегов), то он физически не может привести к их появлению


                                          Говоря проще — сколько бы раз мы гифку не перекодировали, мы на выходе будем получать одно и то же изображение. А какой-нибудь джипег с каждым разом будет деградировать все больше и больше, создавая артефакты, потому что в процессе перевода сырого изображения в сжатую форму совершаются те самые операции с потерей данных


                                          Определения видов сжатий были придуманы не мной и не сегодня, зачем с ними спорить?

                          +1
                          Тоже так подумал.
                          Хорошо если есть исходник, тогда качество будет лучше, но сжимать гиф в видео вообще плохая затея.
                          А гиф с дезирингом видеокодек вообще нормально не сожмёт.
                        +1
                        Ну а если у пользователя совсем старый девайс или навигатор, который видео не поддерживает вообще (что крайте маловероятно с H264), то он просто увидит GIF
                        Вот бы кто подсказал, как с современными девайсами так сделать. А то уже выбешивают сайты, которые под видом GIF отдают MP4.
                          +1
                          Для картинок (и gif в том числе) во всех браузерах есть встроенная в контекстное меню команда «Сохранить». Для видео почему-то нет. То есть конечно можно поставить какой нибудь плагин к браузеру (но они не всегда корректно работают). Но по умолчанию — нет.
                          Лично мне очень не нравится, когда у меня отнимают возможность свободно делать с контентом что угодно — в первую очередь сохранять себе на диск.
                            +1
                            Firefox 67 без дополнений, есть сохранить видео, и текущий кадр.
                            Да и в любом случае можно глянуть исходник в HTML и скачать видео по ссылке.
                            Заголовок спойлера

                              +1
                              Возможно, автор комментария пытался скачать потоковый материал, который со стороны выглядит как обычное видео в нативном плеере браузера, но на самом деле представляет собой HLS-стрим или MPEG-DASH-стрим из кусков, которые грузятся один за другим согласно плейлисту. Для таких опция «скачать видео» недоступна. Попробуйте, например, дважды кликнуть правой кнопкой по видео на YouTube.
                              0
                              Тут проблема двоякая: если все видео выкладывать в виде одного большого «streamable»-файла, то его, во-первых, может с легкостью скачать любой желающий, и, во-вторых, он будет просто безжалостен к трафику, ибо весь, скажем, фильм размером в гигабайт и более будет сразу скачиваться от начала и до конца при запросе (если только браузер не достаточно «умен», чтобы приостанавливать загрузку далее текущего положения ползунка в плеере).

                              Чтобы это исправить используют т.н. HTTP Live Streaming. Плюсы: видео заранее порезано на части по несколько секунд (причем в разных качествах для разных сетей — от быстрых, до очень медленных), которые передаются браузеру в виде плейлиста со ссылками на все куски. Клиент может быстро переходить к нужному участку видео, получить возможность выбора дополнительных аудиодорожек, которые реализованы таким же образом, экономит трафик, поставив видео на паузу (грузится, скажем, 30 секунд, после чего буферизация новых «кусков» прекращается) и еще много плюсов как для мобильных клиентов, так и для соседей по дому, которые так же хотят смотреть стримы на твиче и видео в YouTube. Но минус такого решения, конечно, в том, что чтобы скачать такое видео, нужно выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg. Однако к большинству браузеров существует туча плагинов, которые умеют перехватывать HLS-трафик, к примеру, и сшивать видео в один файл на диске.
                                +1
                                выкачать все куски (часто отдельно — и для видео, и для аудио) и «сшить» их вместе, скажем, с помощью ffmpeg

                                Достаточно дать ffmpeg ссылочку на плейлист и он сам скачает и склеет.


                                Вроде так:


                                ffmpeg -i https://example.org/stream.m3u8 -c copy out.mkv
                                  0
                                  www.stream-video-downloader.com — и любой желающий может скачать любое DASH видео с любого сайта за один клик, включая rutube. Youtube не поддерживает из-за лицензионных ограничений, но тут есть другие, тот же Download Master.
                                  0
                                  Картинка всегда единый файл (да и тот же канвас всегда можно сжать из памяти «по месту»).
                                  Современное же видео это, кроме псевдо стриминга из обычного mp4 файла еще и
                                  DASH
                                  HLS
                                  WEBRTS
                                  Которые не получиться просто взять и сохранить в файл.

                                  upd: нужно приучить себя обновлять страницу перед отправкой комментария — выше ответили более развернуто.
                                  0
                                  На Вивальди все есть
                                  image

                                    0
                                    Lighthouse радуется когда видит видео вместо гифов, и справедливо — разница действительно значительная. При замене гифов на видео я стандартно получал из 1.5М — 300К.
                                    Единственная большая проблема это прозрачность. VP9(8) не работают в Сафари, к сожалению ( а айфон — наше всё ). Это решается только хитрым методом
                                      0
                                      Там, куда мы направляемся, нам не понадобятся GIFы!

                                      Github давно зовут, но к сожалению пока не идёт что-то. :(

                                        0

                                        Очень круто! Вообще поражает скорость разработки и принятия решений во многих проектах сейчас.

                                          +1

                                          Меня интересует вопрос: если я могу сейчас с условного сайта скачать GIFку и легко прикрепить на другом сайте или отправить в вк, то что делать с этим видео? Как будут реализованы такие возможности? Потому что на сайтах которые заменяют гифки на видео это превращается в гемморой

                                            +1
                                            В жизни большинство вещей имеют свои плюсы и минусы. Когда вы заменяете GIF на видео, минусов чаще всего найти не получится.

                                            К чему было это писать, если в комментариях расписали предостаточно минусов:


                                            • Очень медленное кодирование.
                                            • Отсутствие аппаратной и даже программной поддержки.
                                            • Видео нельзя просто сохранить или копировать.
                                              +2

                                              Обратите внимание, что в процитированном предложении говорится про видео в целом, а не конкретно про AV1.


                                              • H.264 легко кодируется в реалтайме, libx264 достаточно оптимизирован.
                                              • Аппаратная поддержка H.264 встроена чуть ли не в каждую кофеварку.
                                              • В любом нормальном браузере есть пункт меню про сохранение видеофайла.
                                              +1
                                              Сейчас бы в 2019 говорить о методах, которые толком смартфонами не поддерживаются. При том, что доля смартфонов выше доли десктопов во многих сферах.
                                              А еще мобильные браузеры идут к тому чтобы выключить автовоспроизведение даже для видео без звука…
                                                0
                                                Как веб-разработчик, вы хотите минимизировать вещи, которые пользователям нужно скачать, чтобы сайт загружался быстро. По той же причине вы минимизируете JavaScript, оптимизируйте PNG, JPEG, а иногда и конвертируете JPEG в WebP


                                                Судя по большиству сайтов в интернетах веб-разработчики делают строго противоположное…
                                                  0
                                                  Речь идёт о разработчиках, которые, возможно, прочитают эту статью.
                                                  0
                                                  2025 год, видео окончательно заменила GIF.
                                                  На Хабре продолжают выкладывать 4к-фотографии в PNG.
                                                    0
                                                    Кто-нибудь знает как создавать ВКонтакте гифки, которые проигрываются сами и почему такое есть? Я коллекционирую такие, они грузятся-выкладываются под видом PNG, но изучить причину пока нет возможности. Пересохранение такой картинки портит возможность обманывать эту соцсесть.
                                                      0
                                                      APNG?
                                                        0
                                                        Действительно, APNG работает так же. Но те всё же гифки внутри.
                                                      0
                                                      Linux Debian stable. PaleMoon 28.2.2.
                                                      Ни VP9, ни AV1 не работает.
                                                      Остаёмся с «тёплым, ламповым» GIF.

                                                      Вы лет этак через 10 заглядывайте, тогда может у будет актуально… :)))
                                                        +1
                                                        А H264 тоже не работает?! Не верю :)
                                                          –1
                                                          Ничего не работает. Человек сам себе напорождал проблем, а теперь стонет. Можно и Windows 98 в 2019м водрузить и с MS IE 5.5 куда-то там пытаться зайти, но смысл?
                                                          0
                                                          Забыли кодеки установить?

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое