Видеозаписи AV1 в файлах MP4 до 5 мегабайтов на страницах Telegraph в 2022 году

За пару лѣтъ, прошедших со времени написания обзора «Публикация в Telegraph видеозаписей в формате AV1 объёмом до 5 мегабайтов» (то есть с осени 2020 года), основные четыре мысли того обзора осталися всецѣло вѣрными:

1. Страницы на сайте Telegraph можно иллюстрировать не только видеозаписями, расположенными на внѣшнихъ видеохостингах (YouTube, Vimeo и проч.), но также и видеофайлами, загруженными непосредственно на сайт Telegraph. Это позволяет отстоять содержимое файла от посягательств на право цитирования (совершаемых под предлогом защиты авторских прав на первоисточник видеоцитаты), или от западной цензуры, или просто сохранить качество видео неизмѣннымъ (не подвергнутым дополнительному переужатию видео, совершённому на стороне видеохостинга).
2. Сайт Telegraph принимает только видеофайлы MP4 (напримѣръ, WebM не принимает, так что никакие видеостикеры и анимированные эмоджи въ неизмѣнномъ видѣ не получится перенести из Телеграма на сайт Telegraph) и по объёму не болѣе 5 мегабайтов (5 242 880 байтов).
3. В скромный пятимегабайтовый объём всё же можно, сохраняя сносное качество, помѣстить видеозапись, длящуюся цѣлую минуту или даже двѣ (с натяжкою — три минуты), но только если прибѣгнуть к самому современному из видеоформатов, в WWW поддерживаемых — к формату AV1 (со звуком Opus) в контейнере MP4.
4. У новизны и у больших возможностей этого формата есть обратная сторона: компания Apple ещё не успѣла обеспечить поддержкою AV1 свои мобильные устройства.

Технически же за два года в возможностях пятимегабайтовых видеозаписей AV1 произошли нѣкоторыя измѣненія:

① повысилась возможная глубина цвѣта,

② стал возможным просмотр AV1 на смартфонах (кроме эппловских),

③ ускорилось видеокодирование,

④ затруднилась расстановка ключевых кадров.

Ниже я постараюсь подробно рассказать про каждое из этих измѣненій.

Рост глубины цвѣта

Как обстоят дѣла с глубиною (битностью, разрядностью) цвѣтовъ?

А вот как:

Однако в том же 2020 году я ещё не стал, несмотря на всю её благотворность, рекомендовать своим читателям тридцатибитность пикселов в AV1. Декодировщик dav1d, разработанный для просмотра видео AV1 видеопроигрывателем VLC и широчайше используемый для той же цѣли в других видеопроигрывателях (напримѣръ, в Media Player Classic Home Cinema) и во браузерах WWW (как во Chrome, так и в Firefox), ещё не обладал достаточной для того мощностью, так что тридцатибитные видео AV1 неприятно заикались или подёргивались.

К нашему счастью, с 1 августа 2021 года новая версия dav1d (версия 0.9.1) стала обеспечивать въ нѣсколько разъ болѣе быстрое декодирование видео AV1 с десятибитными и двѣнадцатибитными компонентами цвѣта, так как соѿвѣтствующая часть кода декодировщика была цѣликомъ переписана на языке ассемблера. Черезъ нѣсколько дней я упомянул об этом в Twitter:

(В настоящее время стёрта та блогозапись про новинку dav1d, которую сочинил Jean-Baptiste Kempf и на которую я ссылался из Твиттера. К счастью, его сочинение сберёг Архив Интернета, так что с ним ещё можно ознакомиться. Если же оно исчезнет и оттудова, то на этот крайний случай я сохранил скриншот у меня в Твиттере, как сами можете видеть выше.)

Затѣмъ какое-то время продлилось внедрение нового dav1d в новые версии браузеров. Во Chrome это произошло быстрѣе, чѣмъ в Файерфоксе (потому что Firefox как раз запускал поддержку графического формата AVIF, на AV1 основанного, и не рисковал обновлять dav1d до этого). Но и Firefox обзавёлся ускоренным dav1d в своей версии Firefox 95, выпуск которой состоялся 7 декабря 2021 года.

Поэтому к середине июня нынѣшняго (2022) года и Chrome, и даже Firefox подошли съ болѣе чѣмъ полугодовою поддержкою тридцатибитных пикселов в видео AV1. Без их поддержки остаются очень, очень немногие пользователи этих двух браузеров — только такие, которые обновляют браузер раз в год или ещё рѣже.

Слѣдовательно, сейчас можно совершенно свободно использовать тридцатибитность пикселов в AV1 как средство «бесплатного» наращивания качества (или длины) видео на сайте Telegraph и не беспокоиться о том, что видео тормознёт.

Напослѣдокъ не скрою, что мнѣ всё же удавалось наблюдать «заикание» тридцатибитных видеозаписей AV1 в современном Файерфоксе, но:

1. Это происходило на компé с процессором болѣе чѣмъ десятилѣтней давности (Core i7-3770, чьё производство компания Intel начала въ апрѣлѣ 2012 г.), а современная техника обрабатывает видеокадры быстрѣе, обладая возможностями AVX2 с 2013 года.
2. Это были такие видеозаписи, в которой тридцатибитных пикселов было много (3840×2160 пикселов, кадр UltraHD 4K). А так как видеозаписи ультравысокой чёткости много вѣсятъ, то их, скорѣе всего, не удастся помѣстить на сайт Telegraph: не пролѣзутъ в пятимегабайтовое ограничение по объёму.

Вы можете поэтому об этом моём наблюдении не беспокоиться на страницах сайта Telegraph.

AV1 на смартфонах

Осенью 2020 года в своём обзоре я называл поддержку формата AV1 отсутствующею во браузерах на большинстве мобильных устройств.

Совершенно тот же сайт «Can I use…», на который я тогда ссылался, теперь (осенью 2022 года) в своей таблице свѣдѣній про поддержку AV1 показывает, что обстоятельства нѣсколько улучшилися:

Теперь положение дѣлъ выглядит так:

1. Браузер Chrome (самый популярный из мобильных) и всѣ тѣ браузеры, которые работают на его движке, поддерживают AV1.
2. Safari на iOS не поддерживает AV1.
3. Firefox на Android по умолчанию (кроме его бета-версий) не поддерживает AV1, но поддержка может быть включена через настройки «about:config». (Впрочем, это должно мало нас заботить, потому что популярность мобильного Файерфокса — доля процента, а популярность его беты — ещё меньше того.)

Начало поддержки AV1 мобильным Хромом совпало с переходом к использованию декодировщика dav1d этим браузером в марте 2021 года. Я не считаю это случайным совпадением. Скорость работы dav1d принесла свои плоды.

Ускорение видеокодирования

В первые годы существования AV1 установилось (и не беспочвенно) то мнѣніе, что эталонная реализация кодировщика AV1 (а именно движок libaom-av1) работает изрядно медленно.

В августе 2020 года при AOMedia была создана рабочая группа, нацѣленная на развитие интеловского и нетфликсовского кодировщика SVT-AV1 для этого же видеоформата.

25 ноября слѣдующаго (2021) года на Реддите появилась вот такая картинка из доклада Intel про возможности SVT-AV1, по которой сразу стало ясно, что год прошёл не зря:

Нѣсколько раньше этого (7 ноября 2021 года) на канале Streaming Media на YouTube появилась видеозапись «AV1 — Accelerating The Adoption». Там можно было увидать (на ѿмѣткѣ времени 10:25 от начала видео), как David Ronca («Director, Video Encoding, Facebook») показывает ту же сáмую картинку и рассуждает о её смысле.

Суть такова:

1. Кодировщик SVT-AV1 превзошёл всѣ кодировщики видеоформатов, до AV1 появившихся, по эффективности видеосжатия при равной скорости работы. Даже кодировщики предшествующего поколения (x265, libvpx) превзошёл болѣе чѣмъ на 20%, а уж x264 — примѣрно на 70%.
2. Для любого пресета (то есть режима работы) любого из этих прежних кодировщиков (кроме x264 в «сверхбыстром» режиме) можно подобрать такой пресет для SVT-AV1, при котором SVT-AV1 будет работать одновременно и быстрѣе, и эфффективнее. То есть одержит безоговорочную побѣду.
3. Также у SVT-AV1 есть (но отсутствуют у кодировщиков предшествующих форматов) ещё три пресета для болѣе медленной и болѣе эффективной работы. Разница по скорости между самым быстрым и самым медленным пресетом примѣрно тысячекратна, предоставляя огромную ширь выбора: можно по-быстрому закодировать видеозаписи, для которых не нужна экономия объёма файла и траффика при просмотре (скажем, архив видеонаблюдения, нечасто проглядываемый), а можно потратить много времени на кодирование видеозаписей, для которых нужна экономия объёма файла (потому что им придётся помѣститься в пятимегабайтовое ограничение сайта Telegraph) или экономия траффика (потому что их будут смотрѣть многие тысячи или даже миллионы пользователей Нетфликса, Ютьюба, Фэйсбука, etc.). На всѣ случаи годится один и тот же кодировщик, достаточно его просто перенастроить.
4. Самый медленный пресет SVT-AV1 работает всё же замѣтно быстрѣе (и чуточку эффективнѣе), чѣмъ самый медленный пресет libaom-av1.
5. Ещё болѣе новый видеоформат VVC располагает кодировщиком vvenc, способным опережать SVT-AV1 по эффективности, однако не болѣе чѣмъ на 5% при сходной скорости работы или на 10% при многократно болѣе медленной. И так как употребление VVC требует лицензионных отчислений держателям патентов, то напрашивается вывод о том, что результат того не стóит.

В марте нынѣшняго (2022) года, когда я набрёл на эти свѣдѣнія и стал осваивать SVT-AV1, мнѣ достаточно было только перейти с libaom-av1 на libsvtav1 для того, чтобы кодирование (двухпоточное и при ≈равном битрейте) ускорилося на 72⅜%:

Днём позже (также в марте) я убедился ещё, что SVT-AV1 при указанном CRF превосходно работает в однопроходном режиме (тогда как libaom-av1 требовал двух проходов), а слово «Scalable» в его названии — не пустой звук, а отражает сильную распараллеленность его операций над видеоданными (закон Амдала не так сильно наказывает собою этот кодировщик, как libaom-av1), так что не приходится раздѣлять кадр на подкадры (tiles), обрабатываемые параллельно, как приходилося для libaom-av1. Притом наращивание количества тайлов слегка вредило эффективности видеокодирования, тогда как эффективность SVT-AV1 (и содержимое получающегося видеофайла) совершенно не зависит от количества потоков его работы.

Для меня всего этого было вполне достаточно для того, чтобы перейти к употреблению SVT-AV1 во всѣхъ случаях изготовления видео AV1.

Но всё же моё сравнение скоростей работы SVT-AV1 и libaom-av1 будет не вполне полным без двух замѣчаний:

• Работа над ускорением и распараллеливанием libaom-av1 также продолжается. К сентябрю 2022 года там появилась параллельная обработка кадров, сокращающая общее время работы на двадцать-тридцать процентов в зависимости от количества тайлов.
• В третьем квартале 2022 года работа SVT-AV1 под Windows серьёзно (многократно!) замедлилась. Это было нежелательным эффектом измѣненій исходного кода, которые накатили 23 июня для другой цѣли (чтобы побѣдить переполнение стэка под macOS), а затѣмъ откатили 1 октября, когда их пагубность стала очевидною. Рассматривая оцѣнку эффекта, нетрудно счесть замедление ≈трёхкратным для седьмого пресета и ≈шестикратным для четвёртого. Весьма возможно предполагать, что ещё болѣе медленные пресеты работали ещё медленнее во всё это время.

Произошедшее нимало не принудило меня усомниться в выборе, сдѣланномъ в пользу SVT-AV1 в марте. Вы же, если вдруг встрѣтится какое-нибудь сравнение скоростей libaom-av1 и SVT-AV1, сдѣланное под Windows в третьем квартале нынѣшняго (2022) года не в пользу SVT-AV1 (особенно сдѣланное в сентябре!), будете знать настоящий источник впечатлений автора такого сравнения.

Расстановка ключевых кадров

Поглядите вот на это окно настройки «горячих клавиш» в видеопроигрывателе Media Player Classic Home Cinema:

В этом списке команд (и назначенных им «горячих клавиш») не очень трудно замѣтить команды «Jump Forward (keyframe)» и «Jump Backward (keyframe)», которые проматывают видео къ слѣдующему или к предшествующему ключевому кадру.

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

Если же ключевые кадры расставлены в видеофайле не просто так, а сюжетно обусловленным способом, то тогда каждый ключевой кадр — это первый кадр нѣкоторой сцены видео. Одна из команд, показанных на скриншоте, тогда приобретает новый смысл «промотать к началу слѣдующей сцены», а другая — «повторить (заново показать) эту сцену с сáмого начала». Причём началом сцены в той и другой команде оказывается именно сáмое-cáмое начало ея (без опасности «промазать» и начать просмотр чуть позже или чуть раньше), поскольку именно там располагается ключевой кадр.

Располагается он там в том случае, когда его польза учтена создателями видеокодировщика:

Слѣдовательно, вот каковы четыре благоприятных послѣдствія от расстановки ключевых кадров в начале сцен:

① проматывание удобно,

② объём файла не распухает,

③ качество кадров не просѣдаетъ,

④ удобно цитировать начало сцены.

Говоря о послѣднемъ из этих послѣдствій, я подразумеваю прежде всего ту возможность сохранения ключевого кадра из видео AV1 в файл AVIF (сохранения, совершаемого без внесения каких-либо потерь), о значении которой я рассуждал 26 мая на моём канале в Телеграме:

Понятно, что если ключевые кадры стоят в начале новой сцены, то этим полезным способом из видеофайла можно копировать кадры, имѣющіе больший сюжетный смысл (так как разумный сценарий сцены удѣляетъ больше внимания началу и завершению ея, нежели середине).

Если же копируется не один кадр видео, а много (для создания анимированного AVIF или нового AV1 с видеоцитатою внутри), то и такое копирование опять же может совершиться без потерь только тогда, когда первый кадр — ключевой. И когда ключевым является первый кадр нѣкоторой сцены, тогда вся сцена годится для копирования без потерь (и без опасения прирѣзать к ней или отрѣзать от неё лишние кадры).

А драма тут в том, что всѣ три открытых и свободных кодировщика AV1: и libaom-av1, и rav1e, и SVT-AV1 — не вполне идеально (и подчас нѣсколько удивительно) подошли къ дѣлу разстановки ключевых кадров в видеозаписях.

Движок libaom-av1 иногда «клинит» (к счастью, не всякий раз), и тогда он начинает ставить ключевые кадры не в начале сцен, а в конце. При этом иногда для экономии страшно похѣриваетъ их качество, а иногда — качество других кадров. Но даже когда и не похѣритъ ни того, ни другого, то и тогда этот изыск с ключевыми кадрами, возникающими «на ровном мѣстѣ» без возможности переиспользования их информации в качестве опорной, оказывается неблагоприятен для общего соѿношенія качества и объёма файла. Много тому примѣровъ!

Разработчики движка rav1e в его вики сообщают (в настоящее время), что rav1e кодирует каждый кадр по два раза (один раз как ключевой, другой раз как предсказанный по сосѣдямъ) для того, чтобы надёжно понять, какой итог кодирования получится больше по объёму и не пора ли поставить новый ключевой кадр, чтобы начать им новую сцену:

Сложно поспорить съ тѣмъ, что надёжность тут так и прёт — но безспорно и то, что достигается она двукратною избыточностью кодирования каждого видеокадра! Половиною, половиною скорости работы rav1e пожертвовали! Ѽ, етить!

Разработчики же SVT-AV1 обеспечили эффект диаметрально противоположный: сочинили (по их мнѣнію, по меньшей мѣрѣ) настолько высокоэффективный кодировщик первого кадра сцен, что тот стал способным всегда достигнуть меньшего объёма, чѣмъ объём ключевого кадра. То есть подход, принятый в rav1e, всегда приводил бы в SVT-AV1 к отказу от создания ключевого кадра.

Это привело к двум любопытным послѣдствіямъ.

Во-первых, в SVT-AV1 добавили (в качестве необязательной возможности) режим почти полного отказа от создания ключевых кадров (кроме сáмого первого кадра файла), включаемый параметром keyint=0. Выигрыш по объёму от этого я оцѣнилъ в марте как равный 5% и немало тому дивился:

Вот примѣръ видеофайла, полученного этим способом:

Его важным недостатком становится затруднённость навигации:

Во-вторых, принятый в SVT-AV1 процесс расстановки ключевых кадров в начале новых сцен сперва считался неоптимальным, а затѣмъ 19 марта был отключён.

На первый взгляд вроде бы логично: если начальный кадр сцены всегда занимает меньше, чѣмъ ключевой кадр, то пусть таким он и остаётся в видеопотоке. Экономия!

Однако расстановка ключевых кадров, перестав происходить в начале сцен, начала происходить просто-напросто через равные промежутки времени — и тѣмъ лишилась тѣхъ четырёх благоприятных послѣдствій болѣе разумной расстановки, с упоминания которых я начал свой рассказ о ключевых кадрах.

Наиболѣе замѣтнымъ послѣдствіемъ равнопромежуточной расстановки сдѣлалося просѣданіе качества кадров.

В качестве первого примѣра такого просѣданія посмотрите видеоцитату того монолога, который Хикигая Хачиман произносит в восьмой серии второго сезона аниме «Орэгаиру»:

Сразу перед двумя ключевыми кадрами в ней (расположенными на 60,06 и на 80,08 секунды от начала цитаты) становятся видными (но ненадолго — на ⅙ секунды) такие группы кадров (по четыре кадра в каждой группе) съ просѣвшимъ качеством, которые начинают собою свои сцены. Кодировщик автоматически счёл возможным сэкономить на их качестве, так как ключевые кадры подпирают собою качество остальной сцены, слѣдующей за ними.

В качестве второго примѣра такого просѣданія посмотрите видеоцитату того монолога, который Роршах произносит в начале кинокартины «Watchmen» 2009 года:

В этом втором примѣрѣ взаимное положение ключевых кадров и начал сцен противоположно наблюдавшемуся в первом примѣрѣ. Кодировщик автоматически погубил качество ключевого кадра на ѿмѣткѣ 60,06 секунды и качество ещё тринадцати слѣдующихъ кадров, потому что всѣ они — небольшой хвост сцены, за которым близко слѣдуетъ начало новой. Кодировщик автоматически погубил качество ключевого кадра на ѿмѣткѣ 140,14 секунды и качество ещё трёх слѣдующихъ кадров, потому что всѣ они — небольшой хвост сцены, за которым близко слѣдуетъ начало новой.

(И тот, и другой примѣръ показывает реальное состояние результатов работы SVT-AV1 в августе 2022 года.)

Не в силах хладнокровно переносить такой недостаток, в начале октября я освоил PySceneDetect и начал использовать это средство в качестве источника позиций ключевых кадров в начале сцен, независимого от кодировщика. На примѣрѣ цитаты из аниме «Mawaru Penguindrum», меметически передѣланной в пропаганду установки Linux, я убедился в том, что по совѣту PySceneDetect могу расставить ≈вдвое больше ключевых кадров и притом получить видеофайл объёмом на 2% меньше, чѣмъ если позволить SVT-AV1 расставлять ключевые кадры через равные промежутки времени:

Получается, что вышеупомянутая «на первый взгляд логичная» экономия за счёт переноса ключевого кадра прочь из начала сцены оказывается маловажною: её превозмогает собою то обстоятельство, что «цѣна кадра» (выражаемая количеством тѣхъ байтов, которые в файле затрачиваются на хранение кадра) складывается таким образом, что въ этомъ примѣрѣ «дешевле» расставить двѣнадцать ключевых кадров в начале сцен, чѣмъ шесть ключевых кадров «в случайных мѣстахъ» (которые «случайныя» только с точки зрѣнія сюжета видео, а так-то строжайше соѿвѣтствуютъ двадцатисекундным интервалам).

И насколько же выходит «дороже» сдѣлать ключевой кадр из серединного кадра сцены (который в противном случае оказался бы двунаправленно предсказанным по его сосѣдямъ и оттого «дешёвым») по сравнению съ тѣмъ, чтобы ключевым сдѣлать начальный кадр сцены (который в любом случае содержит крупную междукадровую разность и оттого «ужé дороговат»)? — приходится умозаключить, что болѣе чѣмъ вдвое «дороже» обходится такая «добавленная стоимость»!

Либо разработчики SVT-AV1 сами же себя обмишулили со своею попыткою экономии на расстановке ключевых кадров, либо их расстановщик и впрямь был хуже, чѣмъ PySceneDetect, так что не мог достигнуть равной ему экономии и даже нѣсколько раздувал объём файла.

В том и в другом случае дѣло расстановки ключевых кадров никак нельзя довѣрить кодировщику SVT-AV1, а приходится довѣрить PySceneDetect или какому-нибудь аналогу.

Лично я пока что аналоги искать не стану, у меня и PySceneDetect неплохо справляется — не без недостатков, но я научился справляться с ними:

Притом же изслѣдованіе, проведённое в МГУ, показало в 2020 и в 2021 году, что у PySceneDetect не слишком много реальных конкурентов, а удобных при запуске из командной строки — и того меньше.

Примѣры

Каждое видео в этих примѣрахъ кодировалось в SVT-AV1 с использованием тридцатибитных пикселов и нулевого пресета, а расстановка ключевых кадров совершалась по указаниям PySceneDetect с учётом их недочётов при необходимости.

Примѣръ цитаты из кинофильма — первый из монологов Роршаха в «Watchmen»:

Этот монолог ужé использовался какъ примѣръ в моём предыдущем обзоре возможностей пятимегабайтных AV1, так что на этом примѣрѣ нетрудно видѣть рост качества, достигаемый использованием кодировщика SVT-AV1 вмѣсто libaom-av1.

В моём нынѣшнемъ обзоре я также ужé показывал (в предыдущем видеопроигрывателе) именно этот монолог (но тогда изготовленный без участия PySceneDetect) как примѣръ просѣданія качества кадров, происходящего в том случае, когда за ключевым кадром слишком близко слѣдуетъ начало новой сцены. Вы можете видѣть теперь на его примѣрѣ, что использование результатов работы PySceneDetect исключает такое расположение ключевых кадров и устраняет просѣдание качества.

Примѣръ музыкального видеоклипа — Dan Vasc, поющий кавер пѣсни «Bring Me To Life» Evanescence:

Поёт он на изрядно однотонном чёрном фоне, что обеспечивает значительную сжимаемость видеоданных, возможность в пять мегабайтов умѣстить без малого 3¾ минуты видео безъ замѣтной потери качества.

Первый из аниме-примѣровъ — сцена о персонажицах, пристрастившихся к жирной лапше, из девятой серии «Ramen Daisuki Koizumi-san»:

В этой видеоцитате мало динамических сцен и много зарисовок различной жирной лапши и подающих её лапшичных, что и позволяет умѣстить больше 4 минут в пяти мегабайтах. Однако видны уж и признаки чрезмѣрности такого видеосжатия: в начале четвёртой минуты видеосжатием скрадываются движения губ бесѣдующихъ персонажиц, а во второй половине той же четвёртой минуты сѵмволическая сцена падения лепестка сакуры распадается на квадратики макроблоков — и распад этот видеофильтрация не в силах была устранить въ полной мѣрѣ.

Второй из аниме-примѣровъ — та (болѣе чѣмъ трёхминутная) цитата из восьмой серии второго сезона аниме «Орэгаиру», в которой Хикигая Хачиман произносит свой монолог о взаимопонимании:

Выше я ужé показывал именно эту видеоцитату (но тогда изготовленную без участия PySceneDetect) как примѣръ просѣданія качества кадров, происходящего в том случае, когда за началом новой сцены слишком близко слѣдуетъ ключевой кадр. Вы можете видѣть на её примѣрѣ теперь, что использование результатов работы PySceneDetect исключает такое расположение ключевых кадров и устраняет просѣдание качества.

Обратная связь

Для репоста и комментирования пользуйтеся упоминанием этого моего обзора в Телеграме и в Твиттере: