Компания Meta, властями России признанная экстремистскою, сообщила на позапрошлой недѣлѣ во вторник (21 февраля) об очередном значительном достижении: видеоролики Facebook Reels и Instagram Reels теперь будут доставляться ко зрителям в формате AV1.

Если прочесть сообщение Meta повнимательнѣе, то тогда сдѣлается ясно видно, какой выбрали видеокодировщик (SVT-AV1) и какой выбрали декодировщик (dav1d) и какими соображениями при этом руководилися.

Выбор SVT-AV1 в качестве кодировщика опирался на ту же подборку графиков (вдоль горизонтальной оси — время кодирования, вдоль вертикальной — проценты отношения качества к объёму файла), о смысле которой рассуждал в ноябре позапрошлого (2021) года David Ronca («Director, Video Encoding, Facebook»). Постоянные читатели моего канала могут помнить, что я сослался на это рассуждение и приложил эти графики в обзоре «Видеозаписи AV1 в файлах MP4 до 5 мегабайтов на страницах Telegraph в 2022 году».

Выбор dav1d в качестве декодировщика продиктован, с одной стороны, результатами тестирования (согласно которым dav1d на большинстве устройств способен без заикания показывать 30 кадров в секунду для видео 720p на большинстве мобильников, но подымается и до возможности справиться с видео 1080p на устройствах как дорогостоящих, так и среднего цѣнового диапазона), а с другой стороны — пониманием того, что на другие декодировщики нельзя полагаться. На компáх нельзя полагаться на аппаратные декодировщики формата AV1, потому что ими оснащены только новѣйшія видеокарты Intel и nVidia. На мобильниках под Android нельзя полагаться ни на аппаратные декодировщики формата AV1, потому что они есть только въ наиболѣе новых (и притом недешёвых) устройствах (скажем, Google Pixel 6 Pro или Samsung Galaxy S21), ни на программный декодировщик libgav1 (встроенный в систему Android), потому что тот уступает dav1d по возможностям (так что libgav1 будет тормозить и заикаться при воспроизведении таких видео, с которыми dav1d всё ещё справился бы на том же устройстве). На эппловских устройствах нельзя полагаться ни на аппаратные, ни на программные декодировщики AV1, так как нѣтъ ни тѣхъ, ни других в готовом виде: всё приходится приносить с собою.

Именно так разработчики Meta и поступили: принесли с собою, так что послѣднія версіи приложений Facebook и Instagram внутри себя содержат dav1d и именно им декодируют видео AV1 в своих видеопроигрывателях.

Выбор, подобный этому, на нѣсколько лѣтъ раньше (не позднѣе 2019 года) пришлось сдѣлать и разработчикам браузеров. Вы найдёте декодировщик dav1d встроенным во браузеры Google Chrome и Mozilla Firefox как на компáх, так и под Android. Без dav1d поддержка AV1 во браузерах была бы гораздо хуже.

А что же Telegram? — а Telegram медлит, и именно этим вызваны послѣднія словá моего предыдущего сообщения, осуждающие отставание Телеграма от Фэйсбука. Сейчас внедрение dav1d в приложения Телеграма находится ещё только на стадии первого шага:

① Telegram Desktop обзавёлся поддержкою AV1 ещё под конец прошлого (2022) года, и этой новинке я порадовался 8 января. Технически поддержка AV1 достигнута именно использованием декодировщика dav1d, так что даже на компáх ≈десятилѣтней давности видео AV1 не заикается, если это TrueColor fullHD на 30 кадров в секунду. (Не заикается и тогда, когда использует только один из способов выхода за упомянутые мною рамки: либо 4K вмѣсто fullHD, либо 60 кадров в секунду вмѣсто 30 кадров, либо тридцатибитные пикселы вмѣсто TrueColor.)

② Telegram под Android не содержит dav1d и оттого принуждён полагаться на возможности libgav1. Слѣдовательно, показ AV1 начинает подтормаживать въ тѣхъ наиболѣе динамичных сценах видео AV1, которые dav1d декодировал бы без заиканий.

③ Telegram под iOS также не содержит dav1d, но оттого вообще не может декодировать AV1.

Что же дѣлать?

Во-первых, пожалуйста, лайкните предложение о поддержке AV1 в Телеграме.

Во-вторых, установите видеопроигрыватель VLC (для iOS или для Android). Движок dav1d был придуман именно для нужд VLC. Вы сможете посмотрѣть в VLC видеофайл AV1, если сперва скачаете видео из канала в файл на смартфоне.

Сшил (в Overmix) нѣкоторые кадры первой серии #аниме «HenSuki».

Сшивки прилагаю в формате PNG внутри архива 7-Zip.

Альбом — на сайте Telegraph.

Сшил (в Overmix) нѣкоторые кадры первой серии #аниме «Arifureta Shokugyou de Sekai Saikyou».

Сшивки прилагаю в формате PNG внутри архива 7-Zip.

Альбом — на сайте Telegraph.

Сейчас название формата GIF неразрывно связано с анимациями. Видя файл GIF, современный пользователь ожидает увидать в нём анимацию (потому что для неанимированной картинки скорѣе всего подыскали бы формат поновѣе и получше); болѣе того, зачастую словом «GIF» зовут уж и всякую другую анимацию, не обязательно хранимую в формате GIF (так, напримѣръ, поступает и Telegram).

Но так было не всегда.

Без малого тридцать шесть лѣтъ назад (15 июня 1987 года), когда компания CompuServe представила восхищённой публике формат GIF, это сáмое восхищение публики вызвано было прежде всего тѣмъ, что самая примитивная форма сжатия данных о пикселах (RLE), с 1985 года работавшая въ болѣе раннем графическом формате файлов PCX корпорации ZSoft, оказалась ужé через ≈два года превзойдена сжатием LZW, заложенным в формат GIF. (Для обладателей тогдашних модемов, которые нынѣшнему пользователю показались бы чудовищно низкоскоростными, каждый лишний килобайт, сэкономленный небывалым способом сжатия данных, воспринимался как серьёзное подспорье.) Другою значительною возможностью, также заложенною в GIF с сáмого начала и также существенно облегчавшею жизнь тогдашним пользователям малоскоростных каналов связи, была необязательная возможность создания чересстрочных GIFов, строчки пикселов в которых хранились въ измѣнённомъ порядке, что позволяло зрителю сперва скачать только каждую восьмую строчку пикселов (чтобы пораньше получить смутное представление о картинке), затѣмъ каждую четвёртую строчку, каждую вторую, и наконец — оставшиеся.

Ещё через ≈два года (в 1989 году) появился второй (он же и послѣдній) вариант формата GIF, в котором возможность хранения нѣсколькихъ изображений впервые была осознана как анимационная, однако (и это нам опять же трудно вообразить) тогда анимации GIF были придуманы не в качестве зацикленных: создатели формата ограничились добавлением возможности указать величину междукадровой задержки (столько-то сотых долей секунды) и возможности сдѣлать фон прозрачным, но не зациклить GIF.

Любопытно прибавить к этому, что Anthony T. Holdener III упоминает (на 435 странице руководства «Ajax: The Definitive Guide»), что первые браузеры поддерживали только один цвѣтной графический формат (GIF) и ещё один чёрно-бѣлый (XBM), пока появление формата JPEG (в сентябре 1992 года) и его поддержка во браузере Mosaic (начальная версия которого вышла в январе 1993 года, а первая по номеру — въ апрѣлѣ того же года или в ноябре; но я не нашёл, сразу ли она содержала поддержку JPEG) не прибавила к ним ещё этот третий формат. Получается, что первые пользователи WWW должны были цѣнить формат GIF просто как средство передачи по WWW цвѣтныхъ картинок (если у кого в том году ужé был цвѣтной дисплей), причём передачи для послѣдующаго открытия в окне системного просмотрщика (поскольку, как вспоминает сам Berners-Lee, только с появлением Mosaic дѣло дошло до показа картинок непосредственно на web-страницах).

Отсчитав ещё пару лѣтъ от появления Mosaic в 1993 году до появления Netscape Navigator версии 2.0 в сентябре 1995 г., мы наконец приходим к тому историческому моменту, который впервые принёс в WWW поддержку зацикленных анимированных GIFов (и на память о котором каждый зацикленный анимированный GIF обязан содержать строчку «NETSCAPE2.0» безъ пробѣла).

Таким образом, в 2023 году наступает тридцатилѣтіе возможности показывать картинки на web-страницах, и 28 лѣтъ исполнится появлению зацикленных анимаций.

Кроме того, в 2023 году наступает тридцатилѣтіе Бѣлой Книги (the White Book), то есть стандарта VCD (он же Video CD), изданного в 1993 году и начавшего эпоху массового распространения цифровых видео. Для контраста можно припомнить, что к тому времени ≈полтора десятилѣтія существовал болѣе ранний формат оптических видеодисков (LaserDisc, появившийся в 1978 г.), но он никогда не был полностью цифровым, а вмѣсто того хранил аналоговый видеосигнал. Появление DVD состоялось в 1996 г., то есть годом позже появления зацикленных анимаций GIF.

А к чему я заговорил о сосуществовании зацикленных анимаций и цифровых видеозаписей?

Ѿвѣтъ — въ слѣдующемъ сообщении.

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

① Тридцать лѣтъ существует широкое распространение цифровых видеозаписей (Video CD, затѣмъ DVD, ещё позже — блюрэи).

② Тридцать лѣтъ существует и возможность помѣщать иллюстрации непосредственно на web-страницах (а не открывающимися въ сосѣднемъ окнѣ).

③ Двадцать восемь лѣтъ такими иллюстрациями могут быть зацикленные анимации (прежде всего в формате GIF, а с течением времени к нему присоединилися и анимированные PNG, и анимированные WebP, и анимированные AVIF, и даже, как в Телеграме, зацикленные видеофайлы MP4).

Откуда появлялись зацикленные анимации, во всё время сосуществуя с цифровыми видеофильмами?

Во-первых, важным источником зацикленных анимаций было и остаётся творчество цифровых художников (и, в частности, pixel art). Вообще цифровая живопись въ нынѣшнемъ году справляет пятидесятилѣтіе (если считать от появления SuperPaint в 1973 г.), но с появлением зацикленных анимаций сформировалось направление цифровой живописи, концептуально нацѣленное на создание именно зацикленных анимаций (начиная, по меньшей мѣрѣ, от циклических движений инопланетян в игре «Space Invaders» 1982 года), а с появлением зацикленных GIF плоды этого направления начали перетекать и въ Сѣть, и вскоре самоограничение создателей pixel art (ограниченное количество и цвѣтовъ, и пикселов, и художественных приёмов) начало восприниматься как неплохо соѿвѣтствующее техническим возможностям формата GIF (ограниченное количество цвѣтовъ, хорошее сжатие однотонных областей и повторяющихся узоров). Причём если и не абсолютно всѣ, то подавляющее большинство нарисованных зацикленных анимаций (как в стиле pixel art, так и менѣе ограниченных) оказываются зацикленными бесшовно, то есть первый кадр в анимации выглядит совершенно таким же, каким ожидается слѣдующій за послѣднимъ кадром, так что при зацикленном воспроизведении никакой «шов» (иными словами, никакой «рывок» при перепрыгивании от конца анимации к её началу) не виден. В каналах наподобие @pixelarts или @pixelartgif нетрудно отыскать превеликое множество примѣровъ этого.

Это во-первых.

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

Очень хорошим примѣромъ является созданный не позднѣе октября 2010 года тумблр IWDRM, цѣликомъ состоящий из кадров извѣстныхъ кинофильмов и видеофильмов, зацикленных бесшовно. Какими средствами пользовался его автор? — по-видимому, кропотливо дѣйствовалъ вручную.

Другим примѣромъ может служить сабрэддит perfectloops, у которого в правилах есть пункт об обязательности бесшовного зацикливания («Must loop seamlessly») и который существует, насколько я понимаю, с 2012 года. Так как я не нашёл там ни одного рассказа о том, каким софтом авторы сообщений создают свои GIFы, то вполне допускаю, что и они всѣ рѣшились дѣйствовать кропотливо вручную.

Ну хорошо, а есть ли способ не вручную, а автоматически находить в видео такие кадры, которые подходят для бесшовного зацикливания?

В 2014 году на сайте Wired было сказано, что Collin Burger сочинил утилиту Loop Findr, служащую такому автоматическому поиску, однако теперь ссылка в Wired оказывается дохлою, а на Гитхабе лежит ссылка на Dropbox (также дохлая) и инструкция, по которой нетрудно догадываться, что Loop Findr не заработает под Windows (а только под macOS). Сайт www.glyph.video предлагает аналогичный софт, но опять же только для macOS.

Так. А под другие операционные системы чего-нибудь есть?

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

Краткое содержание предшествующих сообщений: человѣчество тридцать лѣтъ живёт как с возможностью иллюстрировать web-страницы картинками, так и с широким распространением видеозаписей в цифровой форме, однако оформлять цитаты из видео в качестве зацикленных бесшовных анимаций люди научились сравнительно поздно, а средства автоматизации поиска подходящих кадров можно пересчитать по пальцам одной руки, и бóльшая часть их предназначена для macOS. Для единственного немакосёвого средства (animeloop), с 2018 года мнѣ извѣстнаго, настали непростые времена: автор утратил интерес к проекту (если вообще пережил накатывающиеся вóлны ковида), сайт закрыт, домéнное имя animeloop.org выставлено на продажу.

Но от него осталось нѣкоторое наслѣдіе.

Во-первых, осталось разъяснение метода: автор подробно повѣдалъ, как animeloop руководится итогами тройного хэширования миниатюр кадров, силою которого автоматический поиск рѣдко сбивался и часто получал неплохие результаты, подходящие для зацикливания.

Во-вторых, остался исходный код на Гитхабе. Если почитать приложенные инструкции, то становится ясно, что поставить его на Windows (особенно на семёрку) можно только со скрежетом зубов и томлением духа, поэтому я вздохнул и отвернулся.

(А было это в январе.)

Но на прошлой недѣлѣ удалось получить добрый совѣтъ о том, как можно было продолжить поиск в этом направлении. Оказывается, я пропустил вот чего: в репозитории animeloop на Гитхабе есть подраздѣлъ благодарностей («Special Thanks»), содержащий изъявление благодарности единственному другому разработчику (@ccloli) за помощь, оказанную въ непростомъ дѣлѣ сборки animeloop под Windows — иными словами, въ рѣшеніи как раз той задачи, перед которой я остановился в позапрошлом мѣсяцѣ, не желая тратить время и нервы. У этого-то помощника на Гитхабе донынѣ сохраняются форки исходного кода, и в каждом из форков — по одному-единственному готовому релизу animeloop для Windows: первая сборка совершалася посредством Visual Studio 2015, вторая — посредством mingw-w64-x86_64-gcc 8.3.0-2.

Без малѣйшаго промедления я скачал первую из этих сборок и убедился в полной работоспособности ея.

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

\путь\к\animeloop-cli.exe --thread 6 --max-duration 12.5 --min-duration 0.4 --output . --input аниме.mkv

Завершив работу, animeloop оставляет созданными двѣ подпапки (для цитат и для кэша), причём в имени файла каждой видеоцитаты (сохраняемой в MP4) указывается начальный и конечный номер кадра, которыми можно воспользоваться, когда захочется экспортировать найденные видеокадры в формате PNG без внесения потерь:

ffmpeg -hide_banner -i аниме.mkv -vf "trim=start_frame=начальныйНомер:end_frame=конечныйНомер,setpts=PTS-STARTPTS" frames\%6d.png

Есть двѣ причины, по которым такое может захотѣться:

① В качестве AVC-кодировщика (при сохранении видеоцитат в файлы MP4) animeloop использует OpenH264. Это избавило автора animeloop от обязанности платить лицензионные отчисления правообладателям видеоформата AVC, однако не лучшим образом сказалося на качестве сохраняемых кадров. Пересохранив видеокадры в формате PNG без внесения потерь, можно затѣмъ изготовить бесшовно зацикленную анимацию в другом видеоформате, не требующем лицензионных отчислений правообладателям (напримѣръ, в VP9 или в AV1), или ограничиться анимированным графическим форматом файла (создать анимированный GIF, анимированный PNG, анимированный WebP, анимированный AVIF, анимированный JPEG XL, etc.).

② Когда зацикливанию подвергается не особенно динамичная сцена аниме, тогда каждые два-три кадра подряд бывают одинаковыми, а найденные animeloop границы сцены могут потребовать коррекции в бóльшую или меньшую сторону, чтобы достигалася не только визуальная, но и временнáя бесшовность (не только наличие одинаковых кадров в начале и в конце сцены, но и нужное количество их).

Рассказ про способ запуска animeloop я сопроводил двумя сообщениями-предисловиями и двумя примѣрами результатов (бесшовных циклических анимаций).

Первый примѣръ, выложенный на три дня раньше, был взят из полнометражки «Манускрипт ниндзя» (1993 г.).

Второй примѣръ, выложенный сразу опосля основного рассказа, был взят из полнометражки «Курэнай дэнсэцъ» (2019 г.).

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

(Здѣсь в качестве примѣра прилагаю зацикленную цитату из «Криминального чтива».)

Однако в игровом кино такие цитаты не настолько совершенны, как в аниме:

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

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

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

Ѿдѣльною причиною для досады становится ограниченность тѣхъ форм, которые итог зацикливания способен принять: жалею, что Telegram не понимает ни анимированные PNG, ни анимированные WebP или AVIF.

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

Правда, довольно сложно в точности узнать, какими были ограничения кадра первого из популярных стандартов видеозаписи, а именно видеокассет VHS (стандарт 1976 года): число строк кадра этой системы опредѣлялося используемым телевизором (480 строк для американских телевизоров NTSC, 576 строк для европейских телевизоров PAL) и имѣло конкретный физический смысл (это буквально строки, проходимые электронным лучом в трубке тогдашних телевизоров), но вот понятие «число пикселов в строке» не имѣло конкретного значения для тогдашних аналоговых сигналов, поэтому его значение спорно. Какъ извѣстно, Википедию время от времени редактируют; и доредактировалися до того, что сегодня про строки VHS в ней приведены сразу двѣ оцѣнки. Первая из них сообщает, что горизонтальная чёткость равнялася 240 твл (а значит, 240×4×⅓=320 пикселов в каждой строке на тогдашних экранах 4:3). Вторая оцѣнка, ссылаясь на пособие «DVD Demystified», сообщает, что записываемый на магнитную ленту видеосигнал содержал по 333 пикселов в строчках кадров NTSC или по 335 пикселов в строчках кадров PAL. (По-видимому, автор этой оцѣнки счёл горизонтальную чёткость равною ≈250 твл.) Если же вмѣсто Википедии читать сайт Digital FAQ, то тамошняя оцѣнка числа пикселов на каждой строке VHS окажется оцѣночною («250—300») и меньшею каждой из предшествующих.

Для каждой из этих оцѣнокъ мы обнаруживаем кадр VHS сплюснутым по горизонтали ≈двукратно или ещё болѣе (для 480 строк несплюснутым был бы кадр 640×480 пикселов, как в VGA). Википедия прибавляет к этому упоминание того, что цвѣтностная горизонтальная чёткость была всего-навсего сорокапиксельною. Если считать линию содержащею 320 пикселов, то можно представить, что каждые 8 пикселов оказывались одного цвѣта (что напоминает конфликт атрибутов в графических режимах тогдашних домашних компьютеров); реальная ситуация была, разумѣется, сложнѣе, поскольку цвѣта размазывалися несовершенствами аналогового тракта.

Слѣдующимъ весьма популярным стандартом видеозаписей слѣдуетъ считать видео DVD (стандарт 1996 года). О нём в Википедии пишут (но ужé в точности, поскольку видеосигнал цифровой), что DVD допускает (для экономии) ≈половинное горизонтальное разрѣшеніе: 352×480 пикселов для NTSC, 352×576 пикселов для PAL или для SÉCAM. (На вышеупомянутой странице Digital FAQ именно такое число пикселов рекомендуют использовать при оцифровке VHS.) Причём в Википедии эта возможность надписана словами «China Video Disc resolution, 4:3».

Если оттудова перейти по гиперссылке, разъясняющей понятие «China Video Disc», то тогда становится видно, что при создании стандарта Super Video CD (он же SVCD) в 1998 году в него были включены китайские наработки формата Chinese Video Disc (он же CVD), оперативно созданного к 1997 году съ намѣреніемъ откликнуться на появление DVD в предшествующем (1996) году и обеспечить возможность записи на CD видеофайлов в экономном DVD-совмѣстимомъ разрѣшеніи (352 пиксела в строке) в DVD-совмѣстимомъ видеоформате (H.262) с почти совмѣстимымъ звуком (MP2, но с частотою дискретизации 44,1 кГц вмѣсто DVDшных 48 кГц). За счёт этого, с одной стороны, вертикальное разрѣшеніе удвоили по сравнению с прежними CD (в Википедии пишут, что на прежних Video CD было 352×240 пикселов для NTSC, 352×288 пикселов для PAL или для SÉCAM) и перешли к формату H.262 (вмѣсто MPEG-1 на обычных Video CD). С другой стороны, путём дичайшего видеосжатия продолжили запихивать видео на CD, оттянули неизбѣжность перехода на DVD.

В Архиве Интернета сохранилось упоминание и о том, что ещё в 2009 году сплюснутыми по горизонтали (до 544×576 пикселов) были кадры нѣсколькихъ каналов британского цифрового телевѣщанія.

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

14 апрѣля Twitter обрадовал покупателей своей платной услуги (Twitter Blue) новою возможностью публикации таких микроблогозаписей, которыя вообще-то отнюдь уж не «микро», потому что способны будут вмѣщать до десяти тыщщ сѵмволовъ. Частью этой услуги притом сдѣлается возможность выдѣлять текст курсивом или повышенною жирностию в Твиттере.

Постоянные читатели моего канала могут помнить, что наращивание длины твиттеровских сообщений в прошлом было для меня источником нѣкотораго беспокойства: когда оно было ещё только кратким сообщением о том, что Маск доведёт эту длину до 4000 сѵмволовъ, тогда въ послѣднемъ абзаце моего сообщения 13 декабря прошлого (2022) года я размышлял, не распухнут ли вязáнки твиттеровских сообщений, которые я выкладываю в IPFS и затѣмъ гиперссылкою на канал. Позже (в начале моего сообщения 20 февраля) я убедился наглядно, что ничего для меня не измѣнилось с приходом 4000-сѵмвольности, поскольку Twitter начал отдавать усечённые тексты сообщений через тот API (программный интерфейс), которым я их забираю оттудова.

Опираясь на это знание, позавчера я ужé не очень беспокоился о том, сможет ли Twitter нормально обрѣзать десятитысячесѵмвольное сообщение (если смог обрѣзать 4000 сѵмволов, то тогда и с десятком тыщщ должен управиться невозбранно), однако оставалась нѣкоторая неясность насчёт жирного или курсивного текста: какую форму обретёт размѣтка такого текста (будет ли это нѣкоторое подобие языка HTML, или Markdown, или BBCode?), сможет ли мой обработчик переварить её?

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

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

Поискав (в самóм же Твиттере) по словосочетанию «error 32», я увидал только одно подходящее сообщение. Его автор обращался 6 апрѣля к своим читателям с вопросом о том, не знает ли кто-нибудь способ исправить твиттеровскую ошибку 32, но ужé въ слѣдующемъ сообщении собрался просто ждать с мыслью о том, что и у других ботов аналогичная проблема.

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

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

К счастью, всё обошлось: ошибка 32 пропала сама собою, мой обработчик вдругорядь заработал, а Twitter оказался отдающим через API не просто усечённые сообщения, но и избавленные от размѣтки (так что обычным выглядит в них и курсив, и жирный текст). Слѣдовательно, я могу опять (как было и в феврале) ничего не мѣнять в исходном коде обработчика.

Для кого-то этот рассказ — просто «единичный случай» и даже, может быть, «ошибка выжившего»; но кому-нибудь другому удастся извлечь из моей истории тот же совѣтъ, которым Александр Дюма-отец завершил роман про Монте-Кристо:

— Ждать и надѣяться!

☦️ ХРИСТОСЪ ВОСКРЕСЕ! ☦️