Данный браузер не поддерживает воспроизведение видео с кодеком h264 – Проблема с H.264 видео. В разных браузерах работает по разному в пределах одного компьютера, как решить проблему?

Активация поддержки видео в h364 на Firefox 49 на Windows XP / Habr

Почему Firefox никогда не поддерживал видео в h364 на Windows XP, или экскурс в историю

Сначала Mozilla отказывалась поддерживать проприетарный и защищённый патентами формат h364, продвигая использование открытых кодеков, потом, когда стало понятно, что без поддержки h364 в современном вебе никуда, реализовала её при при помощи компонента Windows Media Foundation, отсутствующего в Windows XP. Когда Cisco предоставила открытые и лицензионно чистые кодеки Openh364, было слишком поздно — никто не хотел переписывать рабочий код, использующий WMF, ради ОС, поддержка производителем которой была окончена, и внедрение Openh364 ограничили видео по WebRTC.

Но многие (в том числе и я) всё ещё используют эту ОС по разным причинам, и не стоит им отказывать в просмотре видео в h364 в самом лучшем (по моему скромному мнению) браузере Firefox.

Помощь, откуда не ждали


После обновления на Firefox 48 я внезапно для себя обнаружил, что видео в h364 прекрасно работает.
Небольшое расследование привело меня к тому, что это стало возможно благодаря плагину Adobe Primetime, ориентированному на воспроизведение DRM видео.

На скриншоте ниже, полученном при помощи Process Explorer, видно, что процесс plugin-container, появившийся после загрузки страницы с видео, использует файл eme-adobe.dll из профиля текущего пользователя.

Зайдя в настройку плагинов Firefox, я нашёл там Adobe Primetime, отключение которого приводило к тому, что FF переставал воспроизводить h364, что доказывало, что именно он виновник этого торжества.
Но радость моя была не долгой.

Всё опять сломали


При очередном обновлении до Firefox 49 я с грустью обнаружил, что h364 опять не играется. Я не нашёл Adobe Primetime в списке плагинов, я не нашёл его файлов в профиле, а попытка их подсунуть ни к чему не привела.

В поисках по интернету я наткнулся на обсуждение предложения по скрытию Adobe Primetime на ОС ниже Vista. Оттуда я узнал, что этот плагин официально не поддерживает Windows XP, и на некоторых конфигурациях наблюдались проблемы со стабильностью. Но у меня же проблем не было!

В багтрекере была ссылка на «исправление» проблемы отображения плагина Primetime на XP. Опираясь на код из него, я сделал исправление, которое откатывает вредный эффект данных изменений.

Исправление


Обновление: более простой и корректный способ указан в P.S, файлы править не нужно. Предыдущий вариант исправления остаётся в исторических целях.
Необходимо разархивировать файл omni.ja из корневой директории браузера, найти там файл /jsloader/resource/gre/modules/GMPUtils.jsm, открыть в любом шестнадцатеричном редакторе, и заменить там байты
6973506C6174666F726D416E6456657273696F6E41744C656173740700000077696E0300000036

на
6973506C6174666F726D416E6456657273696F6E41744C656173740700000077696E0300000035

Тем самым мы включим работу плагина на ядре NT 5.0 и выше, вместо NT 6.0. После исправления необходимо упаковать файлы обратно в omni.ja. Архивация с обычными параметрами тут не подойдёт, нужно использовать консоль:
zip -qr9XD omni.ja *

После замены им оригинала всё опять заработало.

Замечу, что необходимо так же активировать поддержку воспроизведения видео при помощи плагинов, в about:config необходимо выставить в true:

media.gmp.decoder.enabled

У меня эта настройка была давно включена, в надежде на работу h364 через Openh364. После этого можно наслаждаться видео в h364 на любых сайтах, в том числе YouTube, Vimeo, сервисах онлайн-трансляций и т.д.


(тест на чистой ОС в виртуальной машине)

Я создал запрос в Bugzilla на возврат поддержки плагина Primetime на Windows XP, но что-то мне подсказывает, что это закончится ничем.
Предлагаю помочь в исправлении описания запроса, так как я косноязычен даже на русском языке (если вы не заметили), а уж на английском понятность моих пояснений полностью теряется, что ещё более снижает шансы на официальное исправление этой проблемы в будущих версиях Firefox.

Послесловие


Для тех, кому лень возиться с HEX- редакторами и архиватором, прикладываю ссылку на каталог на Яндекс.диске, куда я буду сбрасывать свои исправленные файлы omni.ja после обновлений. Пока там лежит один файл из актуальной версии.Замечание для параноиков (коим являюсь я сам)Плагины в Firefox запускаются в изолированном процессе, не имеющим доступ к странице, поэтому ничего страшного в использовании плагина с закрытым кодом нет. Хоть я и предлагаю скачать исправленный файл, я также даю инструкции по его самостоятельному исправлению выше.

Получившийся у вас файл omni.ja при бинарном сравнении может отличатся от моего даже на одной версии FF, так как используются разные архиваторы, его версии и параметры сжатия по умолчанию.


Спасибо за внимание!

P.S. Обновление


На Bugzilla подсказали более простой и корректный способ активации плагина. Достаточно создать в about:config настройку:
media.gmp-eme-adobe.forceSupported

И выставить её в true. Так же необходимо выставить в true уже существующий параметр media.gmp.decoder.enabled, и проверить на всякий случай параметры media.gmp-eme-adobe.visible и media.gmp-eme-adobe.enabled, они активированы по умолчанию, но мало ли. Это позволяет активировать плагин без бинарных патчей файла, поэтому новые версии выкладывать не буду.

Воспроизведение видео H.264 в Firefox 52 на Windows XP

Довольно специфичная задачка по настройке воспроизведения видео формата H.264 плагином расшифровки контента PrimeTime от Adobe Systems таки решилась. Автоматически плагин устанавливаться и работать никак не собирался, пришлось заставить. Спасибо форумчанам — решение собрано из советов по треду форума Firefox.

Исходные данные : Windows XP 32 SP3, Firefox 52.2 ESR

Проверяем доступность H.264 через страницу: https://www.youtube.com/html5

Решение проблемы воспроизведения видео H.264 по шагам :

* Скачиваем архив с кодеком primetime_gmp_win_x86_gmc_40673.zip — приложен в конце материала.

* Открываем папку профиля Firefox текущего пользователя :

C:\Documents and Settings\Пользователь\Local Settings\Application Data\Mozilla\Firefox\Profiles\qylv35n2.default-1403891637125\

Последняя папка «qylv35n2.default-1403891637125» и папка «Пользователь» у вас будут другие.

* Создаем вложенную папку gmp-eme-adobe\17

Получаем каталог вида

C:\Documents and Settings\Пользователь\Local Settings\Application Data\Mozilla\Firefox\Profiles\qylv35n2.default-1403891637125\gmp-eme-adobe\17

и в него распаковываем содержимое архива — 3 файла.

* Открываем Firefox. В адресной строке идем в настройки : about:config

* устанавливаем фильтр  media.gmp-e

* Добавляем или корректируем параметры :

 media.gmp-eme-adobe.enabled -> true

 media.gmp-eme-adobe.forceSupported -> true

 media.gmp-eme-adobe.visible -> true

 media.gmp-eme-adobe.version -> 17

 media.gmp-eme-adobe.abi -> x86-msvc-x86

Важно! Два последних параметра строковые!

Получится так как на 2-й картинке.

Проверяем еще пару параметров (они уже есть в настройках) :

 media.gmp.decoder.enabled -> true

 media.eme.enabled -> true

* Перезагружаем Firefox. Проверяем работоспособность видео.

Поддержка в Google Chrome видео формата H.264.

Веб-видео HTML5 снова появилось, на этот раз с известием, что Google объявила убрать поддержку кодека H.264 в браузере Chrome. Менеджер Google ProductМайк Jazayeri  признаёт, что «H.264 играет важную роль в видео», но Google решила направить свои ресурсы исключительно «на полностью открытый кодек технологий».

Что это означает для пользователей Chrome? Chrome будет в конечном итоге поддерживать только веб-видео HTML5, которое делают возможным использование собственного WebM Google (VP8) кодека или кодеки Theora видео, и отказывается проигрывать H.264 видео, если веб-сайт имеет потоковое видео в этом формате. Хотя это не относится к Youtube и, возможно, нескольких других сайтов, большинство интернет-сайтов не будут кодировать свои видео несколько раз, чтобы убедиться, что они могут вопроизводится во всех браузерах.

Давайте взглянем на браузеры и их поддержку HTML5 видео:

*Google Chrome WebM8, Theora

*Firefox, WebM8, Theora

*Опера, WebM8, Theora

*Internet Explorer 9, H.264

*Safari, H.264

Google Chrome до сих пор был браузером, который поддерживает все видео кодеки. У интернет-пользователей теперь есть проблема, их любимый браузер не сможет проиграть видео, которое они хотят смотреть в Интернете, что означает, что они должны держать второй установленный браузер, или скачать видео на компьютер, чтобы смотреть его на компьютере.

H.264 является Blu-Ray и кодеком для Apple,который использует его в своих продуктах. Если вы посмотрите на развлекательные устройства,вы заметите, что большинство проигравет H.264, но не WebM или Theora.

Большинство комментаторов на официальном блоге Google Chrome, не согласны с Google. Собственный кодек Google пытается протолкнуть за счёт пользователей Chrome, другие утверждают, что WebM8 кодек H.264 уступают по качеству. Что вы думаете по этому поводу? И как вы справляетесь с веб-видео HTML5?

P.P.S. Если у Вас есть вопросы, желание прокомментировать или поделиться опытом, напишите, пожалуйста, в комментариях ниже.

Как организовать воспроизведение h364 в браузере с минимальной задержкой? — Хабр Q&A

Пробую оргазанизовать видеотрансляцию с камеры в браузер, клиент всегда один. В итоге нужно получить задержку близкую к нулю и очень желательна кроссбраузерность, по крайней мере поддержка десктопных Сhrome+Firefox+Opera+Safari(по мере уменьшения надобности) полугодичной древности.

Для теста организовал RTMP сервер на nginx, передавая на него видео (720×1280 30fps) Gstreamer’ом. Дальше чтобы замерить минимальную возможную задержку устроил воспроизведение rtmp потока опять же через gstreamer. результат — задержка в 2-3 кадра. Дальше пробую добиться того же, но через браузер:

1) Flash.
Из плюсов — кроссбраузерность, простота в плане кодинга, у большинства пользователей он уже установлен. И еще шикарная плюшка — возможность вещать через UDP (меняем RTMP на RTMFP), что уменьшит задержки при передаче пакетов. НО! Не удалось достичь задержки меньше 8 кадров , извращался всяко разно, буферизацию повыкручивал на ноль, но без толку. На самом деле флеш похоже все равно продолжает буфферизировать. Возможно есть какие-то низкоуровневые настройки флешевого декодера, но я их не нашел=(.
2) HTML5
Вроде уже все топовые браузеры понимают html5-video закодированное в h364. Но минимальная задержка (буферы по нулям) порядка 14 кадров. Задержка зависит от браузера. UDP — низя=(
3) Java applet — как костыль (сейчас использую), c gstreamer-java. Задержка идеальна- те же 2-3 кадра, что и при простом проигрывании через gstreamer, что собственно и не странно. Можно вещать через UDP. Но требуется установка джавки клиенту (мало у кого изначально установлена), плюс немного хромает мультиплатформенность, т.к. для каждой ОС и архитектуры нужно подгружать свои библиотеки gstreamer и gstreamer-java.

4) VLC browser plugin. Его еще не полностью затестил, но уже удавалось добиться задержки в 5 кадров. Минусы — требует установки, работает токмо в Firefox.

В идеале — совместить бы плюсы gstreamer-java и флеша… Было бы вкусно!

Авось кому-то удавалось добиться моментальной трансляции в браузер? Прошу помочь!

Как настроить отображение видео по HTML5 в разных разрешениях и разрешить кодеки MSE и h364

Из обсуждения на форуме.

Flash из лисы давно выкинул, но имею одну проблему. На ютубе выбор качества видео скуден: лишь 360 и 720, абсолютно везде. И это после включения всех mediasource параметров в лисе (по умолчанию вообще только 360). Система: Fedore 22 (дома), Ubuntu (на работе).

Кажется, разобрался. Нужно было еще и media.fragmented-mp4 включить. Руки дошли — и все получилось.

Настройку кодеков можно сделать по следующей статье (англ.):

http://www.ghacks.net/2014/07/25/enable-mse-h3-64-support-youtube-firefox-right-now/

Результат будет следующим:

Текст статьи (требуется перевод):

How to enable MSE & h3.64 support on YouTube for Firefox right now

By Martin Brinkmann on July 25, 2014, Last Update: March 6, 2015 34

When you open YouTube’s HTML5 page in the most recent stable version of Firefox right now, you will notice that support is not available for all technologies listed on the page.

Support may be available for HTMLVideoElement, H.264 and WebM VP8, but not for Media Source Extensions, MSE & H.264 or MSE & WebM VP9.

A configuration option is available to enable Media Source Extensions and MSE & WebM VP9 right now in the Firefox browser.

To do so, load about:config in the browser’s address bar and search for the term media.mediasource.enabled there. Double-click the preference to set it to true.

When you go back to YouTube’s HMTL5 page afterwards, you will notice that only MSE & H.264 is listed as unsupported while all remaining options are supported.

If you do not do that, you will only receive select resolutions for videos on YouTube when using the HTML5 video player. This is quite problematic as Google will force Firefox users to use the HTML5 video player from Firefox 33 on.

Mozilla has not enabled the feature by default yet, not even in the most recent Nightly version of Firefox. This is an indicator that the feature is not yet ready for prime time and that it may take a couple of release cycles before it will be enabled by default.

Most video resolutions become available after you enable Media Source Extensions in Firefox. What is still not supported afterwards however is MSE & H.264 which means that some videos may not play in all resolutions yet on the site.

Enable MSE & H.264

A new preference in Firefox Nightly 34 changes that however, so that support for all requested technologies is provided afterwards on YouTube.

Note: While the article concentrates on Google’s video hosting platform, enabling support for MSE & H.264 will benefit users of the browser on other websites as well.

You need to create a new preference to do so:

  1. Type about:config and hit enter.
  2. Confirm you will be careful.
  3. Right-click and select New > Boolean.
  4. Name the preference media.mediasource.ignore_codecs.
  5. Set its value to True.

Update: Linux userrs may change the following preferences as well:

  1. media.mediasource.mp4.enabled to true
  2. media.fragmented-mp4.* to true
  3. media.fragmented-mp4.use-blank-decoder to false

If you go back to YouTube’s HTML page, you should see all six technologies listed as supported (in green).

Several bugs need to be resolved before the feature will be enabled directly by Mozilla for all users of the browser. You can check out the mediasource progress here.

This means that you may get hangs or experience other issues after enabling mp4 container support for Media Source Extensions in the browser.

Still, it is great to see that Mozilla is working on support for the feature in Firefox. It is unclear if it will manage to resolve all issues before Firefox 33 gets released, as it may result in an increase in support requests when Firefox users notice that YouTube is serving them only some resolutions.

если надо посмотреть видео с YouTube на старом ноуте

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

А вот на стареньких ноутах все видеокрасоты YouTube выглядят уже не так симпатично. И хотя процессор загружен по полной, машинка греется со страшной силой, батарея садится буквально со свистом, но, тем не менее, качестве видео весь этот перенапряг почти не сказывается. Оно все равно плохое.

Потому раз со стратегией не получается, то приходится находить какие-то варианты на тактическом уровне. Можно оперативки доставить (к слову, о том, где и по чем можно кyпить оперативную память в Укpaинe), «дрова» обновить.  Либо в самом крайнем случае — уменьшить разрешение до 320p или даже до 144p (если надо ролик хоть как-то посмотреть), но тогда получается не просмотр видео, а уже как бы немножко анекдот.

Но есть еще h364ify

Данное решение в виде расширения уже вполне успешно опробовано в браузере Chrome. И вот совсем недавно его аналог те же разработчики выпустили и для Firefox. Что делает h364ify? Если в общих чертах, то данный софт несколько улучшает качество видео с YouTube. Путем его воспроизведения не в стандартных сейчас для этого сервиса форматах сжатия VP8/VP9, а в H.264.

Разницу в картинке глаз пользователя не замечает (или почти не замечает). Но H.264 на старых ноутбуках часто воспроизводится лучше за счет того, что в обработку данных включается графическая система машины (GPU), для которой форматы VP8 или VP9 уже чужие.

Другими словами, аппаратное ускорение за счет возможностей GPU позволяет снизить нагрузку на центральный процессор, что благотворно сказывается на качестве воспроизведение видео.

Кстати, при необходимости вы всегда можете проверить в каком формате проигрывается видео с YouTube на вашем компе. Для этого надо кликнуть правой кнопкой мыши по ролику и в появившемся меню нажать строчку «Статистика для сисадминов». После этого появится новое окошко, в котором помимо прочей информации о видео будет также указан формат сжатия. Обычно там пишут VP8 или VP9, но после установки h364ify там появится video/mp4.

На данный момент времени опций у аддона h364ify всего две. Первая включает или выключает формат сжатия h.264, а вторая автоматически блокирует видео с 60fps.

ускоряем загрузку видео в браузере / Habr

В этом руководстве мы научимся использовать видео в Вебе, как это принято в 2019. Chrome и Firefox начали поддерживать новый кодек AV1 — для них видео можно сделать в два раза меньше.

Отдельно поговорим, как заменить GIF на видео в AV1 и H.264 — тогда его размер упадёт в 20-40 раз.

YouTube уже использует его в TestTube. Netflix заявил, что AV1 будет «их основным кодеком следующего поколения».

Мы в Злых Марсианах уже используем его на нашем сайте и на Ампллифере. В этой статье я поделюсь опытом внедрения AV1 и шаг-за-шагом расскажу, как вставить видео, чтобы оно работало во всех браузерах.

Кодеки и контейнеры


С картинками всё просто: или JPEG с PNG для всех браузеров, или делать более компактные файлы в WebP для современных браузеров. Мы всегда можем быть уверены, что в файлах .png будет PNG-формат (за редким исключением PNG-бомб, от которых может защитить imgproxy).

С видео-файлами всё сложнее. Расширение файла (.mp4, .wmv, .webm или .mov) говорит только о контейнере. В то время, как видео-файлы состоят из трёх различных компонентов:

  1. Видео-кодек определяет как сильно вы сможете сжать видео, и чем придётся пожертвовать. Основные видео-кодеки Веба: H.264, HEVC, VP9 и, теперь, AV1.
  2. Аудио-кодек сжимает звук. Само собой, он не нужен, если в видео нет звука. Популярные варианты: MP3, Opus и AAC.
  3. Контейнер хранит оба видео- (сжатого каким-то видео-кодеком) и аудио-потока (сжатого каким-то аудио-кодеком). А также дополнительные данные, типа субтитров и мета-информации. Популярные контейнеры: MP4, MOV, WebM.

Когда мы видим расширение файла .mp4, мы можем только сказать, что был использован контейнер MP4. А вот кодеки в нём могут быть разные — автор мог взять H.264 и AAC, AV1 и Opus или что-то другое.

Узрите AV1


AV1 — видео-кодек, который был выпущен год назад, в марте 2018. Его создавали, чтобы превзойти кодеки предыдущего поколения — HEVC, VP9, H.264 и VP8.


Диаграмма поколений кодеков от Цахи Левент-Леви

Если вам стало интересно, как именно AV1 удалось превзойти остальные кодеки в сжатии, почитайте технические подробности в переводах на Хабре:
«Видео следующего поколения: представляем AV1»
«Кодек нового поколения AV1: корректирующий направленный фильтр CDEF»

За счёт новых оптимизаций, AV1 сжимает видео на 30—50% лучше, чем H.264 или VP8, и до 30% лучше, чем HEVC. Но кодек был выпущен недавно и пока имеет несколько детских болезней:
  • Текущий кодер не оптимизирован. AV1 сжимает видео очень медленно (новый быстрый кодер на Rust уже в разработке). Кодек не подойдёт для потокового вещания. Если мы говорим о статичных видео на лэндингах — эта проблема нам не актуальна.
  • Пока кодек поддерживается только десктопным Chrome и Firefox под Windows. Поддержки Safari и Edge пока нет (хотя Microsoft уже тестирует её). Надо будет, как минимум, 2 файла: AV1 для Chrome и Firefox и H.264 для остальных браузеров.

Самая крутая штука в AV1 — на низких битрейтах не появляются квадраты «шакализации».


Сравнение качества картинки у разных кодеков на разном битрейте — AV1 выигрывает

Готовим AV1 правильно


Давайте, наконец-то, перейдём к практике. Вначале определимся с контейнером. В теории, AV1 можно поместить в разные контейнеры, но MP4 компактнее и рекомендуется в спецификации. Для звука в AV1 мы возьмём Opus, потому что отлично сжимает звук.

Чтобы видео работало во всех браузерах, мы будем генерировать 3 файла:

  1. Для десктопного Chrome и Firefox на Windows (31% рынка на март 2019): контейнер MP4 с AV1 для видео и Opus для звука.
  2. Для Safari и Edge (16% рынка) — MP4 с HEVC и AAC.
  3. Для остальных: большой MP4-файл с H.264 и AAC.

Можете взять только AV1 и H.264 — видео будет тоже работать у всех.

Для сжатия я рекомендую взять консольный FFmpeg. Есть много графических утилит, но в консоли легче сохранить опции и потом запускать конвертацию автоматически. Убедитесь, что используете именно последнюю версию FFmpeg. Версии до 4.1 не поддерживают AV1 в MP4.

Для Mac OS X:

  1. Установите Homebrew.
  2. brew install ffmpeg

Для Линукса лучше взять свежую сборку с официального сайта — пока во многих дистрибутивах нет версии с поддержкой AV1 в MP4:
  1. wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz
  2. tar -xf ffmpeg-release-amd64-static.tar.xz
  3. sudo cp ffmpeg-4.1-64bit-static/ff* /usr/local/bin/

Для Windows можете установить FFmpeg по руководству Уильяма Диаса.

Переходим к конвертации файла H.264, который нужен нам для старых браузеров. Поскольку все наши файлы используют контейнер MP4, я буду использовать .av1.mp4, .hevc.mp4 и .h364.mp4 постфиксы. Не пугайтесь длинной команды, мы потом её всю разберём:

# Замените SOURCE.mov на путь к исходному видео-файлу

ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libfdk_aac -c:v libx264 -crf 24 -preset veryslow -profile:v main -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.h364.mp4

Теперь откройте video.h364.mp4. Если качество хорошее, а размер большой — попробуйте увеличить -crf (-crf 26 потом -crf 28). Эта опция уменьшит размер файла ценой уменьшения качества. Подбор баланса качества и размера — искусство.
Если исходного видео-файла нет, то можно сконвертировать старый H.264 файл в AV1.

Теперь пришло время для конвертации AV1 — напоминаю, будет дольше H.264. Кодек пока не использует всю мощь процессора (имеет смысл запустить конвертацию нескольких файлов параллельно).
ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libopus -c:v libaom-av1 -crf 34 -b:v 0 -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -strict experimental video.av1.mp4

Снова поиграйте с -crf для подбора идеального баланса качества и размера.

Теперь то же самое для HEVC.

ffmpeg -i SOURCE.mov -map_metadata -1 -c:a libfdk_aac -c:v libx265 -crf 24 -preset veryslow -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.hevc.mp4

Скопируйте video.h364.mp4, video.hevc.mp4 и video.av1.mp4 в корень вашего сайта.

Разбираемся с опциями FFmpeg


Команды выше выглядят как заклинание вызова демона? Не волнуйтесь, это не PostCSS. Давайте разберём опции.

-i SOURCE.mov указывает входящий файл, откуда FFmpeg возьмёт потоки видео и аудио, пережмёт их и запакует в новый контейнер.

-map_metadata -1 удалит мета-информацию из видео (например, программу, в которой видео было создано). В Вебе такая информация редко бывает полезной.

-c:a libopus или -c:a libfdk_aac выставляют аудио-кодеки. Если вам не нужен звук, замените их на -an.

-c:v libaom-av1 выбирает видео-кодек — библиотеку, которая сожмёт кадры видео-потока.

-crf 34 — Constant Rate Factor, баланс качества и размера. Это как слайдер качества JPEG, только он идёт в другом направлении (0 — лучшее качество и самый большой файл). Шкала CRF разная у H.264 и AV1 — у H.264 идёт до 51, у AV1 до 61. CRF для AV1 и H.264 будет разный.

Facebook подобрал примерное соответствие между значениями CRF для H.264 и AV1:
19 → 27, 23 → 33, 27 → 39, 31 → 45, 35 → 51, 39 → 57.

-preset veryslow заставляет H.264 и HEVC кодеки сжимать файл сильнее даже ценой резкого роста времени конвертации.

-profile:v main используется у H.264, чтобы выбрать профиль кодека. Только «Main» будет работать в Safari.

-b:v 0 выставляет минимальный битрейт для AV1, чтобы в видео было постоянное качество.

-pix_fmt yuv420p (формат пикселя) — хитрый способ уменьшить размер файла. Он оставляет оригинальное разрешение для яркости, но уменьшает разрешение для цвета. Наши глаза хуже видят цвет, поэтому не замечают эту хитрость. Удалите эту опцию, если в вашем случае она будет мешать.

-movflags +faststart перемещает всё само важное в начало файла, чтобы браузер мог проигрывать видео до окончания загрузки.

-vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" изменит размер сторон видео к ближайшим чётным (некоторые кодеки могут работать с разрешением 300×200 и 302×200, но не будут работать с 301×200). Если вы уверены, что везде разрешение делится на 2 — можете убрать эту опцию.

-strict experimental нужна для AV1, его кодер ещё экспериментальный.

video.av1.mp4 выставляет имя итогово файла.

Запускаем видео в браузерах


Теперь нам нужно, чтобы каждый браузер загружал видео, которое он поддерживает. Для этого у есть атрибут type. И советую почитать про опции у <video>.
<video controls>
  <source src="video.hevc.mp4" type="video/mp4; codecs=hevc,mp4a.40.2" />
  <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.05M.08,opus" />
  <source src="video.h364.mp4" type="video/mp4; codecs=avc1.4D401E,mp4a.40.2" />
</video>

похожи на выражения if…else — браузер читает их сверху вниз, пока не найдёт тот, чей type он поддерживает.

В type можно указать весь формат файла: контейнер (video/mp4 для MP4), видео-кодек (av01.0.05M.08 для AV1, hevc для HEVC и avc1.4D401E для H.264) и аудио-кодек (opus для Opus и mp4a.40.2 для AAC).

Бонус: как сконвертировать GIF в AV1 и H.264


В 2019 использовать GIF для коротких видео — большой грех. GIF весит в 20—40 раз больше, чем H.264 или AV1. GIF сильнее бьёт по CPU, заставляет аккумулятор утекать быстрее. Если вам нужно короткое зацикленное видео, берите видео-кодеки. И FFmpeg может конвертировать видео прямо из GIF.

Конвертируем GIF в H.264:

ffmpeg -i IMAGE.gif -map_metadata -1 -an -c:v libx264 -crf 24 -preset veryslow -profile:v main -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" video.h364.mp4

Генерируем ещё более маленький AV1:
ffmpeg -i IMAGE.gif -map_metadata -1 -an opus -c:v libaom-av1 -crf 50 -b:v 0 -pix_fmt yuv420p -movflags +faststart -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" -strict experimental video.av1.mp4

Теперь вставим animation.h364.mp4 и animation.av1.mp4 в HTML.
<video autoplay loop muted playsinline>
  <source src="animation.av1.mp4" type="video/mp4; codecs=av01.0.05M.08" />
  <source src="animation.h364.mp4" type="video/mp4" />
</video>

Опции autoplay и loop делают из видео «гифку» — цикленное видео, которое сразу играет после загрузки страницы. playsinline блокирует Safari от открытия видео на весь экран при клике на видео.

Время выводов


AV1 ещё экспериментальный. Но его уже можно использовать, чтобы сделать четверть ваших пользователей счастливее. Пара команд FFmpeg сгенерируют видео-файлы. с самого начала создан, чтобы отдавать видео по возможностям браузеров. Мы уже используем AV1 в продакшене и всё работает отлично (исключая время ожидания, пока AV1-кодер закончит работу).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *