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

Менѣе чѣмъ черезъ мѣсяцъ (1 апрѣля) появилась оцѣнка болѣе оптимистическая — но так как первоапрѣльская, то затруднительно судить, совершенно ли всерьёз: автор вон той замѣтки на сайте Reddit (скриншот прилагаю чуть выше) обратил внимание на то, что развитие AVM (того экспериментальнаго кодека, который в будущем непремѣнно станет основою для эталоннаго кодека AV2) пришло к выпуску очередной версіи его (четырнадцатой), так что понадѣялся на то, что версія эта как раз означает, что AV2 на подходе черезъ нѣсколько дней.

Надежды этого автора не сбылись.

Любопытно поэтому, что прямо сейчас (7 мая) можно повторить его разсужденіе, но имѣя чуть-чуть больше для того основаній.

Во-первых, если тогда приуготовлялся выпуск четырнадцатой версии AVM, то сейчас приуготавливается выпуск пятнадцатой. Когда я пишу эти строки, наверху страницы коммитов AVM (перечисленных там в обратном хронологическом порядке) располагается коммит, помѣченный тегом «research-v15.0.0»:

Во-вторых, в настоящее время на сайте Gitlab я не вижу никаких признаков организованнаго планирования разработки слѣдующей (шестнадцатой) версіи AVM. В частности, очередной «верстовой столб» (milestone) должен для неё имѣть двадцать первый номер, однако по адресу https://gitlab.com/AOMediaCodec/avm/-/milestones/21 открывается (в настоящее время) сообщение об ошибке 404 («Страница не найдена»). Можно сравнить это с пятнадцатой версіею, для которой по предшествующему номеру https://gitlab.com/AOMediaCodec/avm/-/milestones/20 открывается страница планирования с карточками устранённых проблем и графиками производимых работ:

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

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

А сейчас такого явного признака нѣтъ.

В-третьих, для предыдущей версии видеоформата (для AV1) существует изрядно быстрый программный декодировщик (dav1d), который служил всё болѣе неплохим (по мѣрѣ своего совершенствования) подспорьем в декодировании видео AV1 (и изображений в формате AVIF) во всѣ первые годы его существования — и только въ послѣдніе годы вмѣсто него стало можно пользоваться быстрыми аппаратными декодировщиками, да и до сих пор-то они не повсемѣстны.

Ну так вот что: как раз в эти дни разработчики декодировщика dav1d открыли исходный код слѣдующаго декодировщика — dav2d, предназначеннаго декодировать грядущий видеоформат AV2.

(В том сообществе поклонников видеокодирования, которое собирается на форуме Doom9, открытие доступа к исходному коду dav2d замѣтили 2 мая, в сабрэддите AV1 его замѣтили опять же 2 мая — должно быть, тогда оно и состоялося.)

Больше того: в списке недавних правок кода есть и такая, которая помѣчена номером версіи (0.0.1) и въ цѣломъ выглядит подготовкою к выпуску первой публичной версіи dav2d:

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

Не знаю, как вы там, а я считаю совпадение этих трёх сигналов достаточным для того, чтобы слегка обнадёжиться насчёт того, что появление AV2 может состояться ещё до лѣта.

Впрочем, посмотрим.

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

Нетрудно увидать, что первые восемь пунктов списка запланированных ускорений слѣдуютъ друг за другом вот в каком порядке:

① ускорение работы dav2d на современных десктопах — на процессорах, поддерживающих набор команд AVX2,

② ускорение работы dav2d на современных мобильных устройствах — на процессорах, поддерживающих набор команд ARMv8,

③ ускорение работы dav2d на старых десктопах — на процессорах, поддерживающих наборы команд SSSE3 и болѣе новых,

④ ускорение работы dav2d в случае повышенной битности цвѣта на современных мобильных устройствах — на процессорах, поддерживающих набор команд ARMv8,

⑤ ускорение работы dav2d на старых мобильных устройствах — на процессорах, поддерживающих набор команд ARMv7,

⑥ ускорение работы dav2d в случае повышенной битности цвѣта на старых мобильных устройствах — на процессорах, поддерживающих набор команд ARMv7,

⑦ ускорение работы dav2d в случае повышенной битности цвѣта на современных десктопах — на процессорах, поддерживающих набор команд AVX2,

⑧ ускорение работы dav2d в случае повышенной битности цвѣта на старых десктопах — на процессорах, поддерживающих наборы команд SSSE3 и болѣе новых.

Сразу скажу, что лично я понимаю выражение «повышенная битность цвѣта» («high bit-depth») как относящееся к любым пикселам съ глубиною цвѣта большею, чѣмъ у двадцатичетырёхбитных пикселов TrueColor. То есть даже ускорения работы тридцатибитных пикселов (которыми я у себя на канале пользуюсь для видеоцитат в формате AV1) придётся в случае AV2 подождать — а не только ускорения работы сорокавосьмибитных пикселов, напримѣръ.

Ещё скажу вот что: честно говоря, стройной внутренней логики в этом порядке я не увидал. Он вызывает сразу нѣсколько напрашивающихся вопросов:

— Если старыя мобильныя устройства настолько не заслужили высокаго пріоритета в этом списке, что ускорение работы dav2d на них должно подождать до ускорения не только TrueColor, но и тридцатибитных пикселов на современных мобильных устройствах, то тогда отчего же ускорение работы dav2d в случае повышенной битности цвѣта на этих же старых мобильных устройствах должно предшествовать ускорению работы dav2d в случае повышенной битности цвѣта на десктопах?

— Если начальное (для случая пикселов TrueColor) ускорение работы dav2d на современных десктопах настолько значимо, что идёт самым первым в этом списке, то тогда отчего же дальнѣйшее (для случая тридцатибитных пикселов) ускорение работы dav2d на этих же современных десктопах оказывается на предпослѣднемъ мѣстѣ в этом же списке, предшествуя одним только ещё болѣе старымъ десктопамъ?

Прочтение этого списка подводит меня къ нѣкоторому разочарованію. Похоже на то, что не стóит придавать слишком большого значения тому, будет ли завершение разработки стандарта AV2 объявлено этимъ лѣтомъ или всё же чуть раньше — достаточно быстраго (на основе ассемблерных вставок в dav2d) воспроизведения видеороликов AV2 мы всё равно, чего доброго, и до конца 2026 года не увидим ещё.

Правда, должно быть понятным, что есть и такая область примѣненія новинки, в которой достижение большей частоты декодирования кадров имѣетъ куда меньшую значимость — неанимированныя AVIF. И нам ещё предстоит увидѣть даже то, будет ли формат AVIF обновлён (или сочинён новый формат AVIF2 с новым MIME-типом и с новым расширением для имён файлов) вслѣдствіе появления AV2, сколь широкою окажется поддержка его браузеропроизводителями, прогуляются ли по граблям насчёт поддержки анимации в теге <picture> языка HTML5 и проч.

Ѿдѣльная пѣсня съ припѣвомъ — это какими окажутся сроки появления и послѣдующаго обновления поддержки и AV2, и нового AVIF (если будет новый AVIF) не только во браузерах, но и в мобильных операционных системах (в Android, в iOS), и в FFmpeg, и в клиентских приложениях Телеграма (ну, напримѣръ, в Telegram Desktop).

Мнѣ кажется, желание поскорѣе дождаться нѣкоторой опредѣлённости по этому вопросу ещё может оказаться сáмой вѣскою причиною для того, чтобы теперича продолжать ждать появления AV2 с сохраняющимся чувством нетерпения, а не махнуть сию минуту рукою и не перестать интересоваться этим вопросом до конца года.

В языке Markdown существует возможность, извѣстная под названием «link reference definitions» («опредѣленія гиперссылок») и позволяющая указать список URLов и задать им имена (ключевыя словá), которые затѣмъ используются размѣткою гиперссылок и иллюстраций, расположенных до таких опредѣленій или послѣ нихъ.

В сáмом простом виде (без необязательной подсказки) каждое такое опредѣленіе выглядит как ключевое слово (или словá) в квадратных скобках, затѣмъ двоеточие и URL. Примѣръ:

[CommonMark]: https://spec.commonmark.org/0.31.2/#link-reference-definitions
[GLFM]:       https://docs.gitlab.com/user/markdown/#footnotes
[Pandoc]:     https://pandoc.org/MANUAL.html#extension-footnotes
[Telegram]:   https://telegram.org/

Я обнаружил с неудовольствием, что такой блок опредѣленій съ неизбѣжностью ломает работу сносок в том просмотрщике файлов в формате Markdown, который работает въ нынѣшней версіи (v12.7.2) приложения Telegram под Android. Характер такой поломки зависит от положения блока опредѣленій:

➊ Если блок опредѣленій располагается ниже текста сноски в исходном коде, то тогда текст сноски перестаёт быть оформленным в качестве текста сноски.

➋ Если блок опредѣленій располагается выше текста сноски в исходном коде, то тогда гиперссылки в тексте сноски, использующія ключевые слова из блока опредѣленій, перестают быть оформленными в качестве гиперссылок.

Прилагаю два файла в формате Markdown, просмотр которых демонстрирует это.