Есть мрачный старинный анекдот про нѣкотораго книгоиздателя, к которому прибѣжалъ встрёпанный автор одной из изданных книг и умолял немедля отозвать всё изданіе и выпустить другое — с исправлением допущенной ошибки. Книгоиздатель поинтересовался, отчего же такъ спѣшно: разве поступали жалобы от читателей? На это автор ѿвѣчалъ ему, что жалоб никаких не поступало, но это-то как раз и может быть признаком наиболѣе зловѣщимъ — и тогда только книгоиздатель с ужасом вспомнил, что книга та была справочником по опознанию ядовитых грибов. (Правда, с развитием воздухоплавания въ XX вѣкѣ популярным сдѣлался и другой варіантъ анекдота, в котором она была справочником по вѣрному укладыванію парашюта.)

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

Создавать видеозаписи в формате AV1 я начал в 2020 году (первою из выложенных на этом канале, а не в других мѣстахъ, стала вон та), создавать видеоцитаты из аниме я начал ещё раньше (помнится, побудило меня к этому появление возможности выкладывать видеофайлы на Ычан в 2018 году), достаточно быстро этот процесс распался на два шага: сперва я создаю копию цитаты в большом видеофайле, кодированном без внесения потерь, затѣмъ переужимаю его с различными настройками качества, стремясь уложиться в ограничения объёма файла, налагаемыя имиджбордом или Телеграмом. И если второй из этих шагов совершенствуется по нескольку раз в год (напримѣръ, на днях в кодировщике SVT-AV1 появился параметр «enable-kf-tf» для отключения того фильтра, который вносит в ключевые видеокадры такія измѣненія, которыя искажают сами кадры, но которыя усиливают предсказательную силу их в группе кадров и тѣмъ способствуют видеосжатию), то первый я считал совершенно неизмѣннымъ.

И что же? — оказывается, въ предпослѣдній день 2021 года (30 декабря) в ту страницу вики FFmpeg, которая посвящена кодированию видеофайлов в формате AVC (он же H.264), внесены были измѣненія, указывающія на то, что значение параметра «-crf 0» не всегда включает сжатие без потерь, так что лучше использовать значение параметра «-qp 0», особенно для пикселов с большею глубиною цвѣта, нежели TrueColor (24 бита). А въ послѣдній день 2021 года (31 декабря) аналогичный по смыслу отклик (но нѣсколько менѣе подробный) появился и под одним из вопросов на сайте Stack Overflow.

Ну вот я на это наконец наткнулся, пусть и почти на 4½ года позже — что же теперь?

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

Буду ли я и впредь пренебрегать потерями, или же пройдусь по коду всѣхъ тѣхъ моих бáтников (пакетных файлов), которые предназначены для создания несжатых видеоцитат, повсюду замѣняя «-crf 0» на «-qp 0»?

Ни то, ни другое.

Кто обжёгся на молоке, тот дует и на воду. Я собираюсь вообще отказаться от использования формата AVC (он же H.264) даже в том его режиме, который теперича ну уж точно без потерь, правда-правда, никакой ошибки не может быть. (Ну или всё же может, а я опять выясню это черезъ N лѣтъ.) Вмѣсто него я собираюсь использовать тот видеоформат, в котором вродѣ бы любой режим работы обходится без внесения потерь в видеокадры: видеоформат FFV1.

В качестве дополнительнаго преимущества я получаю объёмъ файла на пару десятков процентов поменьше, нежели получался бы в формате AVC (он же H.264) даже в режиме работы «veryslow». В качестве недостатка получаю документацию опять же небезошибочную: прямо сейчас по адресу https://ffmpeg.org/ffmpeg-all.html#ffv1-1 упомянут параметр «remap_optimizer», но попытка использовать его порождает сообщение «Unrecognized option 'remap_optimizer'».

Этот комментарий ↑ о том, по какой причине управление курсором иногда возлагается на буквы H, J, K и L, ссылается на изслѣдованіе, автор которого (Hillel Wayne) завершил его упоминанием о том, что можно было бы компнуть ещё глубже, задавшись и вопросом о том, отчего коды ASCII расположены именно так, как они расположены — но этот вопрос он вообще не намѣревается раскрывать сам, а вмѣсто того отсылает интересующихся читателей ко книге «Coded Char Sets, History and Development» (1980 г.), которую сочинил Charles E. Mackenzie из Корпорации IBM.

При этом адрес книги, на которую Wayne ссылается, ведёт на нѣмецкое зеркало извѣстнаго сайта textfiles.com, у которого есть то общее свойство с Википедиею или с TV Tropes, что на нём (как и в любом неплохо огранизованном хранилище нѣкоторыхъ любопытных знаний) не мудренó надолго застрять.

Зеркало это полезно тѣмъ, что оно (в отличие от основного сайта) поддерживает HTTPS и тѣмъ слегка затрудняет наблюдение со стороны за тѣмъ, кто там чего читает.

Задумка полностью отказаться от использования формата AVC (он же H.264) в пользу формата FFV1 при создании видеофайлов, не вносящем новых потерь в них, которую я огласил 13 мая, могла быть исполнена только для промежуточных видеофайлов при видеоцитировании.

В двух других случаях поневоле пришлось ограничиться (может быть, временно) уходом от «-crf 0» к «-qp 0»:

➊ Экспериментальный способ отправления иллюстраций в Telegram без потерь при сжатии их (но всё же с потерями при субдискретизации цвѣта) предполагает создание зацикленнаго видеоролика, каждый кадр в котором — отправляемая иллюстрация. Этот способ пока ещё не предполагает использование формата FFV1, потому что я нифигушеньки не увѣренъ в способности клиентских приложений Телеграма просматривать видео FFV1, засунутое в видеоконтейнер MP4 (хотя знаю, что технически такое засовывание возможно).

➋ Когда PySceneDetect не в состоянии прочесть нѣкоторый формат видеофайла, мой обычный обходной путь состоит в том, чтобы изготовить копию файла в формате AVC (он же H.264) в надежде на то, что он-то уж точно прочтётся. А вот в способности PySceneDetect читать видео FFV1 я не увѣренъ.

Но, может быть, ещё сдѣлаюсь в этом увѣреннымъ.

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

Постскриптум 17 мая. Я убедился, что PySceneDetect благополучно распознаёт начальные кадры сцен в видео FFV1.

Понадобилось почти двадцать лѣтъ, но всё же русская національная мысль вплотную приблизилася к пониманию зловѣщаго смысла фразы «после смерти Махатмы Ганди поговорить не с кем».

У просмотрщика файлов Markdown в Telegram под Android нѣтъ поддержки иллюстрирования их графическими файлами, как я замѣтилъ 7 мая.

Догадываюсь, что проблема эта может возымѣть пять различных путей рѣшенія, каждый из которых принимает во внимание предполагаемую первопричину проблемы (несмотря на подобие Instant View, просмотрщик файлов Markdown работает локально, а не на сёрвере, так что может выдать IP пользователя хостингу графических файлов), причём не всѣ пути эти выглядят взаимоисключающими:

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

② Как сейчас пользователя спрашивают, желает ли он открыть внѣшнюю гиперссылку, так его можно начать спрашивать, желает ли он открыть такой файл Markdown, который иллюстрирован внѣшними графическими файлами. Или в просмотрщике может появиться кнопка «Дозагрузить изображения», как это было в старинных браузерах WWW времён необходимости жёсткой экономии траффика.

③ Существующее подобие Instant View можно усилить, если загружать внѣшнія иллюстраціи к файлам Markdown не напрямую, а через посредство сёрверов Телеграма — и тѣмъ скрывать IP читателей файлов Markdown.

④ Просмотрщик файлов Markdown мог бы начать показывать хотя бы такие иллюстрации, адрес которых не ведёт на внѣшній сёрверъ за графическим файлом, а полностью содержит файл внутри самогó же адреса, то есть когда файл закодирован кодировкою base64, а результат того кодирования записан в адресе по стандарту RFC 2397. В отдалённом прошлом (когда этот RFC сочиняли) величина URLов считалась ограниченною 1024 сѵмволами (согласно RFC 1866), так что этот подход имѣлъ весьма ограниченную примѣнимость, но сейчас движки всѣхъ популярных браузеров считаются поддерживающими даже адреса полугигабайтовой длины (а просмотрщик файлов Markdown предположительно основывается на готовом движке одного из браузеров гипертекста, не прибѣгая к самописности). Въ нѣсколько менѣе отдалённом прошлом (до 2019 года) теперешнее ограничение объёма файлов Markdown, подлежащих просмотру в Telegram под Android (не больше 65 536 байтов), означало бы возможность засунуть туда только такую иллюстрацию, которая была бы уродливо засорена артефактами чрезмѣрнаго сжатия, но теперешний формат AVIF опережает прежние форматы JPEG и WebP в два или три раза по силе сжатия при равном качестве, а также оставляет менѣе замѣтные и менѣе уродливые артефакты. Для наглядности я прилагаю прямо здѣсь примѣръ файла Markdown, иллюстрированнаго болѣе чѣмъ мегапиксельнымъ файломъ AVIF по стандарту RFC 2397, а всё же не превосходящий 65 536 байтов по объёму.

⑤ Просмотрщик файлов Markdown мог бы начать показывать хотя бы такие иллюстрации, адрес которых не ведёт на внѣшній сёрверъ за графическим файлом, а ведёт только в Telegram же. Относительный адрес вида «имяФайла.webp» мог бы указывать на иллюстрацию, прикрѣплённую с указанным именем к тому же сообщению, что и сам файл Markdown. (На самом же дѣлѣ — к одному изъ сосѣднихъ сообщений того же альбома файлов, потому что альбомы файлов собираются на стороне клиента.)

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

Просмотрщик мог бы преодолѣть ограничение, выучившись распаковыванию архивов (ZIP, 7-Zip, RAR, etc.) и затѣмъ поддержав относительный путь к файлу наподобие «имяАрхива.7z/имяФайла.avif».

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

Составляя примѣръ файла Markdown, приложенный к предшествующему сообщению, я неминуемо должен был обнаружить себя в том положении, когда ужé начинаешь набирать адрес по стандарту RFC 2397:

data:image/avif;base64,

и опосля этой запятой осталось только вставить содержимое файла, кодированное в base64.

В эту-то минуту я и вспомнил, что в моём распоряжении есть сразу нѣсколько средств, способных кодировать в base64: есть команда «certutil -encode имяФайла имяРезультата», а есть и диалоговое окно в файловом менеджере — но что всѣ средства этѣ создают код base64 разбитым на строки (по семьдесят с небольшим сѵмволовъ), чтобы было удобно засовывать его въ электронныя письма, да ещё и снабжают своей шапкою и хвостом, чтобы ѿмѣтить начало и конец кода.

Всякий раз убирать шапку и хвост, а затѣмъ устранять и разбиение на строки (пусть и не руками устранять, а автоматическим поиском и замѣною) — это утомительно. Вмѣсто того захотѣлось сочинить такую команду для командной строки, которая первым параметром принимает имя кодируемого файла (и содержимое того файла кодирует одной длинной строкою base64), а во втором параметре вообще не нуждается, потому что результат свой выводит не в файл (как его выводила бы команда certutil, напримѣръ), а сразу въ буферъ обмѣна, откуда его останется только вставить в Markdown, нажав обычное сочетание клавиш, вставку запускающее (то есть Ctrl+V или Shift+Ins).

И сочинил вот какóй однострочный бáтник (пакетный файл), вызывающий NodeJS:

node -e "process.stdout.write( fs.readFileSync(process.argv[1]).toString('base64') )" %1 | clip

Я также подумал и о том, как будет выглядѣть послѣдняя из мыслей предшествующаго сообщения (идея адресовать иллюстрации внутри Телеграма), если «аппетит придёт во время ѣды» и захочется адресовать не одни только такие иллюстрации, которые лежат в том альбоме файлов, в котором и иллюстрируемый ими файл Markdown, но и иллюстрации в другом альбоме или даже в другом канале.

Возможно ли адаптировать под такое пожелание существующую адресацию, в которой адреса на https://t.iss.one/ начинаются? Возможно, но совмѣстимость ея со внѣшними просмотрщиками окажется иллюзорною: Telegram не позволяет смотрѣть файлы без регистрации — слѣдовательно, сёрвер Телеграма, даже если к нему по адресу https://t.iss.one/ReadMithgol/1175/screenshot.png обратиться, файл с иллюстрациею не отдаст (хотя и сообщение https://t.iss.one/ReadMithgol/1175 существует, и файл screenshot.png в нём лежит); да и внутренний по отношению к Телеграму просмотрщик (в Telegram под Android) должен будет научиться самостоятельно (внутрителеграмным способом) добывать файлы, руководясь адресами, имѣющими такой вид, и затѣмъ скармливать их в качестве иллюстраций в просмотрщик файлов Markdown, такие адреса содержащих.

Но всё равно это лучше, чѣмъ адаптировать внѣWWWшную схему URLoв tg://, в которой аналогом адреса https://t.iss.one/имяКанала/номерСообщения становится громоздкое выражение tg://resolve?domain=имяКанала&post=номерСообщения (и имя файла туда также придётся прибавлять не через косую черту, а через ещё один именованный параметр). И лучше, чѣмъ создавать ещё одну — менѣе громоздкую, но не менѣе внѣWWWшную — схему URLов.

Отчего лучше? — оттого, что иллюзорную возможность внѣшняго просмотра файлов Telegram ещё сможет по своему усмотрению сдѣлать неиллюзорною, когда пожелает (скажем, для файлов меньше опредѣлённаго объёма), тогда как внѣWWWшную схему URLoв ужé никогда не удастся сдѣлать непосредственно обрабатываемою нетелеграмными просмотрщиками файлов Markdown. Никогда, никогда!

(Если же не непосредственно, а опосредованно, то понадобится гейтование. Так получилось с гейтами, ведущими в гипертекстовый Фидонет. Или с гейтами, ведущими въ P2P-распредѣлённую файловую систему IPFS — эти поддерживают не только преобразование адресов ipfs:// или ipns:// в адреса https://, начинающиеся именами гейтов, но и обратное преобразование. Но это потребовало наперёд продумать не только схему адресации файловой системы, но и схему гейтования адресов — и даже формат TXT-полей в DNS-записях, чтобы опознавать гейты в момент обращения к ним по именам!)

Спѣшу прибавить, что командная строка, изложенная в первой половине предшествующаго сообщенія, была бы гораздо проще для понимания, если вмѣсто установленнаго NodeJS я воспользовался установленным Git for Windows, в котором есть готовый кодировщик base64, сочинённый в духе coreutils (или даже на основе coreutils — по правде сказать, я ещё не вникал в его происхождение) и оттого располагающий готовым же параметром для переключения в однострочный режим вывода кода:

"C:\Program Files\Git\usr\bin\base64.exe" -w0 %1 | clip

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

По наводке, выложенной на канале @leaveitru, я зашёл оттудова на канал @karel_terpel и через нѣкоторое время долистал там до мема «Конец 2026, настраиваю SSTV шитпост мемов оставшимся 4 подписчикам», взятого (судя по «водяному знаку» въ лѣвомъ верхнем углу) изъ нѣкоего канала «Калан с мемами».

По этому поводу нѣкоторое время досадливо думал об SSTV: в момент возникновения это была прекрасная технология, но если аналоговое телевидение много гдѣ уступило мѣсто цифровому телевидению, если аналоговое радиовѣщаніе в сколько-нибудь цифровизированных странах (к которым РФ не относится, в РФ даже будущность Интернета под вопросом) также уступило мѣсто цифровому радиовѣщанію, то отчего сохраняется популярность аналогового SSTV без перехода на цифровое вѣщаніе картинок со всѣми достоинствами его (и прежде всего съ помѣхоустойчивостью за счёт информационной избыточности для коррекции ошибок)? — в частности, отчего по сей день картинки наподобие вон той передаются с Международной космической станции таким образом, что на них может воздѣйствовать (а не подавляется) такая вот жирная полоса помѣхъ, как сверху на той картинке?

Погуглил фразу «digital SSTV» и нашёл вон ту страницу с упоминанием приложения EasyPal для передачи цифровых иллюстраций поверх DRM (Digital Radio Mondiale). Разработка приложения заброшена с октября 2014 года. Это фиаско. Ещё нашёл DIGTRX — у этого приложения отзывы на странице также не назвать восторженными. Жалуются опять же на заброшенность и оттого на невозможность запуска на болѣе новых операционных системах.

Въ современномъ мірѣ можно засунуть болѣе чѣмъ мегапиксельное изображение въ менѣе чѣмъ 64-килобитный файл, да ещё мѣсто под гипертекст рядом останется. В это время по радио три минуты передают 640×496 пикселов (напримѣръ), позволяя себѣ единственную форму сжатия информации о них — цвѣтовую субдискретизацию. И радуются тому, что причастилися уровню технологии девяностых годов. А на идею цифровизации смотрят, небось, так же, как фидошники на идею о гипертексте.

Махнул рукою. Ну я же не радиолюбитель. Куда мнѣ во всё это погружаться.

Но это урóк и Телеграму, возможность иллюстрирования сообщений в котором (за исключением прикладывания файлов и стикеров) застряла на уровне JPEG — это же также стандарт 1992 года.

Айда свободу слова! =) Павел Валерьевич, приятного прослушивания от начинающего музыканта, в 14 лет баловавшегося FL и в 32 добравшегося до нейронок )))

Ту пѣсню, которая располагается в предшествующем сообщении, я отфорвардил сюда из комментария к каналу Дурова.

Обратите внимание: упомянуть об этом мнѣ приходится вручную, потому что что в таких обстоятельствах сам Telegram по какой-то причине указывает только автора сообщения, но не тот чат, откудова поступило сообщение. Это поведение Телеграма отличается от того случая, когда сообщение не пересылается, а цитируется: над цитатою-то указывается не один только автор ея, но и чат-источник, как это можно было видѣть, напримѣръ, в моём сообщении 15 мая.

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

Это предсказание моё ↑ оказалось совершенно вѣрным и насчёт «ещё до лѣта», и даже насчёт «слегка»: официальный выпуск видеоформата AV2 планируется хотя и в мае, но всё же весьма близко к концу мѣсяца, а именно 29 мая — как раз эта дата упомянута была вон в той вчерашней правке чэйнджлога, сопровождаясь там краснорѣчивою помѣткою «First released version of AV2».

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

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

Причиною для такой увѣренности было прежде всего то, что ровно недѣлю назадъ (15 мая) состоялась публикация статьи «Video Quality Evaluation Methodology and Result of AV2 Compression Performance», и я пришёл к выводу, что в ней излагается именно окончательная оцѣнка возможностей видеоформата AV2, причём пришёл не по соображениям общего характера (по типу «ну какой смысл публиковать промежуточный результат, если разработка ещё продолжается»), а исходя из приведённых в статье графиков (рисунки №2 и №3), которые показывали, что во второй половине 2025 года рост соѿношенія качества и объёма видеофайла AV2 почти совершенно прекратился и тѣмъ обезсмыслилъ любыя попытки оттягивать выпуск AV2 — вѣроятно, у разработчиков закончилися такія видеоинженерныя идеи, которыя приводили бы къ рѣзкимъ улучшениямъ этого соѿношенія, тогда как плавное совершенствование кодировщика ещё остаётся весьма возможным, но оно-то как раз и не требует дальнѣйшаго совершенствования стандарта формата, потому что оно может (и будет) преспокойно происходить и в нерушимых рамках готового стандарта.

Другой же причиною для такой увѣренности было то, что если в момент предсказания (7 мая) я наблюдал разработку очередной версии AVM не запланированною (и новый milestone отсутствующим) в течение всего только суток, то съ тѣхъ поръ время наблюдения такого отсутствия возросло приблизительно на порядок — и тѣмъ сильнѣе подкрѣпляло собою прежнюю увѣренность мою́.

Появление первой версии видеокодека AV2, вродѣ бы назначенное на 29 мая (то есть на сегодня), по факту состоялось раньше: тег v1.0.0 в его репозитории был проставлен незадолго до часу ночи 28 мая (и это по московскому времени, а в западном полушарии в это время вообще ещё 27 мая было).

Сáмой интересной слѣдующей вѣхой для меня остаётся проникновение поддержки AV2 в формат графических файлов AVIF.

Будет ли оно оформлено как свой собственный новый формат (который назовут AVIF2 или, может быть, AV2IF), который получит своё собственное расширение имён файлов (соѿвѣтственно «.avif2» или «.av2if»), и свой собственный тип MIME («image/avif2» или «image/av2if»), и всё такое?

Или рѣшатся на попытку запустить AV2-в-AVIF просто как новую версию существующего формата AVIF? Пока что с графическими файлами такого, вродѣ бы, не дѣлали ни разу, но в случае видеофайлов это обычное дѣло: напримѣръ, видеофайлы в формате WebM исходно (в 2010 году) поддерживали звуковые дорожки в формате Vorbis и видео VP8, но позже (в 2013 г.) к ним прибавили поддержку звука Opus и видео VP9, а сейчас туда и видео AV1 засовывают — а в видеофайлы MP4 и вовсе можно помѣщать плоды труда очень многих кодеков.

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

Оборотная сторона медали состоит в том, что этот тернистый путь окажется ещё и обходным по отношению к проблемам из серии «курица и яйцо», в которых никто не хочет быть первым среди поддержавших новый формат. («Наша соцсѣть не поддерживает новый формат файлов, потому что пользователи мало им пользуются» супротив «я не собираюсь осваивать новый формат, потому что не смогу использовать ни в одной соцсѣти».) Всѣ просто обновят декодировщик рано или поздно (напримѣръ, с выходом новой версии движка сайта, или новой версии SDK приложений, или новой версии операционной системы) и с ним получат поддержку новой версии формата. Опять же, если нѣкоторая конкретная реализация нѣкотораго языка размѣтки (напримѣръ, Markdown или BBcode) содержит «бѣлый списокъ» разрѣшённыхъ расширений имён файлов, то создателей ея не придётся доставать просьбами прибавить туда «.avif2» или «.av2if», если расширение «.avif» ужé внесено в список.

Ѿдѣльная пѣсня съ припѣвомъ — это, конечно, сроки стандартизации. В своё время от появления черновика видеоформата AV1 (28 марта 2018 г.) до появления формата графических файлов AVIF (19 февраля 2019 г.) прошло десять мѣсяцѣвъ с лишним. Можно ли надѣяться, что теперича дѣло пойдётъ быстрѣе?

А что будет с кодеком libavif? Появится ли у него параметр командной строки, запускающий поддержку AV2-в-AVIF, или появится форк кодека (под именем liavif2 или liav2if) для той же цѣли, или появятся «сборки libavif с использованием libaom-av2 вмѣсто libaom-av1» — чего доброго, ещё и неофициальныя первое время?

И насколько успѣшнымъ и трудоёмким тогда окажется засовывание всего этого во браузеры и когда? — уж точно куда позже того, как в них появится поддержка JPEG XL.

А что и когда появится не на браузерной, а на сёрверной стороне? Если библиотека GD в языке PHP не начала ещё обзаводиться поддержкою JPEG XL, то о поддержке болѣе поздняго формата AV2-в-AVIF нечего и говорить — не успѣютъ не то что к выходу Debian 14 (в 2027 г.), но и к выходу Debian 15 (в 2029 г.), так что на сёрверы всё пріѣдетъ в 2031 году, а до него сейчас аж пять лѣтъ!