Зашёл на 410чан и сперва в обсуждении приёмов сжатия изображений, а затѣмъ и в обсуждении приёмов сжатия видеофайлов повѣдалъ (съ примѣрами) о том, как теперь выглядит моё представление (уточнённое нынѣшнею осенью) о том, как зависит объём получающагося файла от выбора так называемой «матрицы квантования» (quantization matrix) при изготовлении AVIF или AV1.

Скриншоты прилагаю.

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

Сразу напомню ещё, что тогда (в марте 2023 года) первым побуждением моим было посѣтовать на техническое отставание Телеграма от продуктов компании Meta в этом смысле. Но и съ тѣхъ поръ Telegram, насколько я понимаю, так и не улучшил воспроизведение видеофайлов AV1 на мобильных устройствах. В частности, хотя компания Apple обеспечила аппаратное декодирование AV1 сперва в Pro-версиях своих новых айфонов (с сентября 2023 года), а затѣмъ и во всѣхъ остальных версиях (с сентября 2024 года), в Телеграме это никак не используется, так что воспроизведение AV1 нифигушеньки не работает на Pro-версии пятнадцатого айфона, напримѣръ.

Дальше разглядывая эти же графики, нетрудно увидать внизу их ещё вот что: VVenC (кодировщик видеоформата VVC, также извѣстнаго под номером H.266) обнаружен был тогда способным опережать SVT-AV1 (кодировщик видеоформата AV1) по получающемуся соѿношенію качества и объёма видеофайла — но опережать не болѣе чѣмъ на 10% и только въ наиболѣе медленных режимах своей работы.

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

Слѣдовательно, теперь уж нельзя слѣпо довѣряться результатам, достигнутым компанией Intel в 2021 году, а вмѣсто того неплохо бы самостоятельно опробовать видеокодировщики.

На прошлой недѣлѣ я так и поступил: взял тот видеоролик «Basu bango yonbyakujuu バス番号四百十 ED FULL», на примѣрѣ которого здѣсь (на канале) я ужé показывал результаты видеокодирования в сентябре 2022 года и затѣмъ ещё в августе 2023 года, перевёл его видеопоток в формат Y4M с тридцатибитными пикселами (получился файл объёмом больше 35 миллиардов байтов) и затѣмъ скормил кодировщику VVenC, запущенному вот какою командною строкою:

vvencapp --input test.y4m --format yuv420_10 --refreshsec 240 --preset slower --qp 38 --output slower38kf240s.266

Результат прилагаю:

И вот каковы мои основные впечатления и выводы:

① Каждый из трёх кодировщиков для видеоформата AV1: и libaom-av1, и SVT-AV1, и rav1e — существует в официальной сборке для Windows. Однако у кодировщика VVenC официальной сборки для Windows не существует, так что поневоле пришлось скачать и использовать неофициальную сборку нѣсколько болѣе ранней версии (1.12.1-rc1).

② Если сравнивать съ тѣмъ, как в формате AV1 получающийся видеопоток по объёму приближается вплотную к пяти мегабайтам даже при предѣльной величине силы сжатия (CRF=63), то тогда сложно не порадоваться тому, что в формате VVC безразмѣрный показатель силы сжатия, необходимой для этой цѣли, оказывается меньше примѣрно на треть (а если точнѣе, то 38/63 ≈ 60%) и что величина получающегося видеопотока (4 584 083 байта) позволяет дополнить его до пяти мегабайтов аудиопотоком болѣе чѣмъ 23 kbps, обходясь поэтому без сильной экономии на качестве звука.

③ Оборотною стороною этого достоинства является болѣе сильное воздѣйствіе каждой единички, прибавляемой к значению параметра qp в командной строке кодировщика VVenC. Для примѣра сообщаю, что при большей скорости работы («--preset faster») я получил видеопоток объёмом 5 636 318 байтов при «--qp 38», но объём его снизился до 4 932 826 байтов при указании сосѣдняго значения «--qp 39», то есть болѣе чѣмъ на 700 тыщщ байтов. Эта настройка выглядит досадно грубою для видеофайла, весь объём которого запланирован быть пятимегабайтовым.

④ Ещё одной оборотной стороною того же достоинства является возможность достигнуть громадной силы видеосжатия за счёт громадного же ухудшения качества видеокадров. Напримѣръ, ужé с параметрами «--preset faster --qp 50» кодировщик VVenC создаёт видеопоток, битрейт которого не превосходит и 34 kbps (а общий объём равен 960 866 байтов), а видеокадры отличаются досадною мутностью с «замыливанием» или исчезновением подавляющего большинства сколько-нибудь мелких и быстро движущихся элементов изображения. Что там далѣе при «--qp 60» и тѣмъ болѣе при «--qp 64» будет, да и кому (и для чего) эта муть может реально понадобиться и приносить пользу? Да и какую?

⑤ Разница в скорости работы сáмого быстрого пресета («faster») и сáмого медленного («slower») досадно невелика и оттого не позволяет реально быстро (хотя и неточно) узнать, получится ли (хотя бы примѣрно, хотя бы «по порядку величины») желаемый будущий объём видепотока при нѣкоторой выбранной силе сжатия. Если в SVT-AV1 можно переключиться на седьмой и даже на десятый пресет для наращивания скорости видеокодирования, то для VVC максимумом остаётся ≈десяток кадров fullHD в секунду.

⑥ Если сравнивать артефакты AV1 (погрѣшности в видеокадрах, оставляемые кодировщиком SVT-AV1) с артефактами VVC, то ужé на седьмой секунде используемого примѣра становится видно, что VVC лучше передаёт рѣзкое движение вращающегося пропеллера, зато хуже передаёт монотонное движение фигур — замыливает их до такой степени, что у первой же персонажицы исчезли с лица и нос, и рот. Также VVC лучше передаёт плавность равномѣрнаго движения тёмныхъ тѣней по тёмно-синему фону, тогда как в формате AV1 каждое такое движение становится преувеличенно дёрганым (примѣрно каждый второй видеокадр его утрачивается, замѣняясь копиею тѣни из кадра-предшественника). А под конец второй минуты становится видно, что VVC лучше, чѣмъ AV1, передаёт и полёт тёмных листьев на тёмно-синем фоне.

Вы сможете самостоятельно повторить это сравнение артефактов (и даже составить своё собственное мнѣніе о них), если возьмёте приложенный выше видеопоток VVC и будете в каком-нибудь видеопроигрывателе, VVC понимающем (таковá, напримѣръ, сборка clsid2 видеопроигрывателя Media Player Classic Home Cinema), сравнивать его покадрово съ тѣмъ видеофайлом AV1, который я выложил на 410чан для своего сообщения 13 декабря и который я для удобства продублирую здѣсь (но, к сожалению, только внутри архива 7-Zip: если выкладывать не в архиве, то тогда Telegram Desktop упорно норовит оторвать файл WebM от списка файлов и расположить в качестве ѿдѣльнаго видеопроигрывателя — увы, никаким другим способом сладить с ним я не мог):

⑦ По-видимому, скорость работы кодировщиков SVT-AV1 и VVenC, работающих на своих самых медленных пресетах (на минус первом и на «slower» соѿвѣтственно), приблизительно сравнялася: тот и другой расходует в среднем ≈десяток секунд на каждый видеокадр fullHD. Про скорость можно также замѣтить, что видеокодировщик SVT-AV1 неплохо распараллеливает обработку видеокадров, но и VVenC также способен нагрузить 8 потоков параллельною обработкою четырёх видеокадров.

⑧ Артефакты SVT-AV1 нравятся мнѣ много больше артефактов VVC, потому что размытие ≈основных контуров (которые всегда на виду) замѣтнѣе и оттого много досаднѣе, нежели врéменно видное повреждение рѣзкихъ и внутритѣневыхъ движений. Притом же внутри тѣни опять же происходит размытие контуров в VVC, как это видно через ≈сотню секунд от начала видеоролика на примѣрѣ текстуры задняго колеса мотороллера.

⑨ Так как при создании сравниваемых выше видеофайлов я дал кодировщику SVT-AV1 указание не создавать ключевых кадров, то и кодировщику VVenC необходим параметр «--refreshsec 240», значение которого по количеству секунд превосходит общую длину видеоролика (и тѣмъ напрочь исключает возможность создания ключевых кадров), а не то сравнение их качества происходило бы в неравных условиях. (Напримѣръ, с параметром «--refreshsec 20» видеопоток VVC становится меньше 5 мегабайтов только при сосѣднемъ значении качества — при «--qp 39».)

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

⑪ Упомянутая выше возможность дополнить видеопоток до пяти мегабайтов аудиопотоком, когда я попробовал её, внезапно обернулася тѣмъ, что FFmpeg ругнулся словами «Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly» и продолжал браниться словами «pts has no value» во всё время создания видеофайла MP4, а видеопроигрыватель (ужé упомянутый MPC-HC) тормозил при воспроизведении результата. Так как кодировщик VVenC, по-видимому, правильно понимает исходную частоту кадров в файле Y4M (он её выводит на экран в начале видеокодирования), то остаётся предполагать какое-то непонимание мѣтокъ времени кадров, происходящее между ним и FFmpeg — или даже предполагать необходимость болѣе новой версии FFmpeg (а для того и болѣе новой операционной системы), чѣмъ мною сейчас используемая.

#Геленджик, 18 декабря 2024 г., вечер, около половины пятого.

Вид на небо над Центральною площадью и затѣмъ с пляжа в сторону Толстого мыса.

猫