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

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

Во-вторых, хочется ѿмѣтить, что три пресета с сáмой мáлой скоростью работы: и первый, и нулевой, и минус первый — также не сильно замедлилися (первый примѣрно на пять процентов, остальные примѣрно на один), зато получили неплохой рост качества. Если справедлива высказанная на Рэддите оцѣнка, согласно которой рост качества на 3¾% (у четвёртого и пятого пресета) сопоставим с достигаемым от уменьшения CRF на ½, то тогда рост качества на 2½% (который показан у трёх пресетов с наименьшею скоростью работы) сопоставим с достигаемым от уменьшения CRF на ⅓. И так как сам я предпочитаю нулевой пресет, то получу такой рост качества «почти бесплатно» (во всяком случае, сѣтовать о замедлении на 1,1% уж точно не буду).

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

① При прежнем значении CRF объём видеофайла остаётся ≈прежним, единственным измѣненіемъ оказывается возросшее качество видео.

② При прежнем значении CRF объём видеофайла возрастает, однако качество возрастает ещё сильнѣе.

③ При прежнем значении CRF уменьшается достигаемое качество видеозаписи, однако объём видеофайла уменьшается ещё значительнѣе.

④ При прежнем значении CRF объём видеофайла уменьшается, однако качество видео возрастает.

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

Но так как заранѣе, по-видимому, неоткуда узнать, по какому пути улучшение пошлó на этот раз, то придётся прояснить этот вопрос при непосредственном употреблении видеокодировщика. И проясню.

Постскриптум: и прояснил. В вышеозначенной ситуации максимального CRF (63 балла) объём итогов кодирования видеозаписи «Basu bango yonbyakujuu バス番号四百十 ED FULL» (которую я ужé использовал в качестве примѣра в прошлом году и въ нынѣшнемъ) при прочих равных вырастает на 0,04% по сравнению с итогами работы SVT-AV1 версии 1.6 (то есть достигавшимися въ нынѣшнемъ іюнѣ). Можно пренебрегать.

При этом я использовал нулевой пресет.

Постпостскриптум: вторая из видеоцитат аниме «Engage Kiss», используемых в сообщении от 18 августа, в аналогичной ситуации максимального CRF (совершенно необходимого для втискивания 9⅔ минут динамичного видео в пятнадцать мегабайтов) при прочих равных даже уменьшается в объёме на 1,72%, а не только наращивает качество.

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

При этом, в отличие от упоминаемого в постскриптуме, я использовал минус первый пресет.

#Геленджик, 28 августа 2023 г., шесть часов вечера.

Вид на сѣверъ вдоль улицы Айвазовского.

На заднем плане — горный хребет #Маркотх.

#Геленджик, 19 июля 2023 г., 17:20.

Центральная площадь, небо, облака.

Вид на запад (в сторону солнца, неспѣшно движущагося к закату).

Прежде я ужé упоминал на канале (14 июля, то есть ровно два мѣсяца назад), что при иллюстрировании своего канала видеозаписями я предпочитаю видеосжатие по стандарту AV1, которым обеспечивается неплохое соѿношеніе качества и объёма видеофайла — и, в частности, обеспечивается для небольших видеоцитат (меньше шести-девяти минут) возможность умѣститься в 15 мегабайтах (и оттого быть видными даже для зрителей, никогда не регистрировавшихся в Телеграме и просто перешедших по URLам конкретных сообщений канала), а для ещё болѣе небольших (меньше двух-трёх минут) ещё и возможность умѣститься в 5 мегабайтах (чтобы не один только Telegram, но и сайт Telegraph, братский по отношению к Телеграму, мог принимать такие видеофайлы к публикации посредством прямой загрузки на сайт, а не выкладывания их ещё куда-нибудь).

Оборотною стороною достоинств AV1 является удручающе недостаточная поддержка его в мобильных приложениях Телеграма, которые в этом смысле сильно отстают от приложений компании Meta (как от Facebook отстают, так и от Instagram), потому что Telegram опирается единственно на возможности нижележащей операционной системы (то есть Android или iOS), не пытаясь притаскивать с собою программные средства декодирования AV1 (такие, как dav1d). В результате под iOS просмотр видео AV1 возможен только в видеопроигрывателе, внѣшнемъ по отношению к Телеграму (напримѣръ, в VLC), а под Android внутренний видеопроигрыватель Телеграма плохо справляется с поддержанием частоты кадров, если эти кадры достигают хотя бы размѣра fullHD (1920×1080 пикселов), не говоря ужé о бóльших размѣрахъ.

Я, впрочем, всегда говорил себѣ, что для мобильных устройств я создаю AV1 «на вырост», надѣясь на рост возможностей самих устройств или на готовность разработчиков Телеграма догнать коллег из Meta, внедрив dav1d.

В этом направлении меня порадовала компания Apple, 12 сентября огласившая (фрагмент видеокадра прилагаю) намѣреніе снабдить Pro-версии айфонов нынѣшняго года аппаратным декодировщиком видео AV1. И хорошо бы Telegram под iOS им воспользовался.

На второй и на третьей недѣлѣ сентября (примѣрно с пятого по четырнадцатое число) я наблюдал в qBittorrent странное явление: включённая в настройках перепровѣрка скачанных файлов («Recheck torrents on completion») с изрядною вѣроятностью приводила к тому, что опосля перепровѣрки файл воспринимался в качестве полностью некорректного и отбрасывался цѣликомъ, то есть скачивание его начиналося с нуля заново.

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

Я подумал нѣкоторое время и переустановил qBittorrent в таком варианте его версии 4.5.5, который собран был без использования libtorrent 2.0 — и тогда неприятное явление совершенно прекратилося.

У меня есть двѣ идеи истолкования произошедшаго:

① Может быть, протокол BitTorrent v2 настолько ещё малопопулярен, что им ещё не овладела обыкновенная публика, а вмѣсто нея файлообмѣномъ по этому протоколу занимаются либо злоумышленники, в эти недѣли раздававшие мнѣ порченые куски файлов нарочно, руководясь тайным желанием поднасрать, либо борцы за соблюдение авторских прав, руководимые желанием отвратить люд от файлообмѣна раздачею всякой хѣрни вмѣсто желаемых файлов.

② Может быть, при создании libtorrent 2 допущена оплошность — скажем, необходимость сосчитать два хэша (привычный и v2) порождает race condition и успѣваетъ признать файл неподходящим до того, как поступит годный хэш.

То и другое досадно.