Начатое в декабре позапрошлого (2020) года сообщением >>156266 погружение в подробности видеокодирования тридцатибитных пикселов принуждено было завершиться опосля 375 бампов. Здесь — слѣдующая серія.
>>202889 >Microsoft Windows
>>202898 >>202899 Просто ещё раз перечитайте окончание прошлогоднего сообщения >>194319.
Меня по правде всегда удивлял вопрос: "почему ты используешь операционную систему Х?" Такой вопрос подразумевает, что человек использует ровно одну операционную систему, и больше ничего, что по меньшей мере странно. ОС — инструмент, у разных ОС свои преимущества и задачи. И пренебрежение к виндовс выдаёт каких-то десятиклассников, которые вчера открыли для себя линукс. В то время как разработчик-профессионал скорее всего вообще гоняет вимы/тмуксы на макоси с такой-то ретиной, ибо всё уже давным-давно крутится в облаках, виртуалках и контейнерах, и как-то фиолетово, с чего именно ты к этой инфре коннектишься. Я думал, что на автобусе аудитория в основном из взрослых дядек-айтишников, поэтому видеть вот такие посты >>202898 >>202899 неожиданно.
>>202905 Виндовс вперед! Виндовс чемпион!
К сообщению https://t.me/ReadMithgol/725 (в сообщении >>202892 упоминавшемуся) я прибавил, вослѣдъ постскриптуму, ещё и постпостскриптум, содержащий разсмотрѣніе эффекта, новинками libsvtav1 оказанного на послѣднюю из видеоцитат >>/a/19298. Обновлённый скриншот прилагаю.
>>202905 > В то время как разработчик-профессионал скорее всего вообще гоняет вимы/тмуксы на макоси с такой-то ретиной А что это дает?
>>202898 >>202899 Далеко не все люди играют в Arch Linux.
>>202939 Таки да, некоторые играют в Slackware Linux, а кто-то даже в Debian или Gentoo.
>>202954 > играют в Slackware Linux Таких сейчас совсем мало...
>>202954>>202955 Одна девочка NixOS....
>>202975 Хорошая девочка! Другая игродевочка решила тоже потыкать NixOS на сервере в скором времени, может, будет пуни-пуни!
>>202975 Другая девочка может тоже бы, но опасается длительной настройки.
Эппловские чипы A17 PRO будут содержать аппаратный декодировщик AV1 для Pro-версий айфонов. Источник: https://youtu.be/ZiP1l7jlIIA
>>203005 Я не буду покупать.
Файлы WebM на Форчане могут теперь достигать четырёхмегабайтового объёма на большинстве досок. Пруфлинк: https://a.4cdn.org/boards.json
>>203734 4чан - говно с cloudflare picasso
Обоснуй.
И не только >Your web browser must have JavaScript enabled in order for this site to display correctly.
Тот объём видеофайла, который в сообщении >>201664 насчитывал 6 901 685 байтов, а в сообщении >>202452 дошёл до 6 946 386 байтов, а в сообщении >>202892 возрос до 6 948 876 байтов — он не остался неизмѣннымъ и при выходе новой версии SVT-AV1 (версии 1.8.0, достоинства которой вы можете увидать в коммите https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/0c357a7efed2a65f7ae3136b31e9cb1cdcf06d40 перечисленными, а табличка измѣненій скорости и качества по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2143 приводится). Теперь этот видеофайл занимает 6 799 678 байтов, так что нетрудно видѣть рѣзкое сокращение объёма видеодорожки до такого уровня, который в своём распухании результат подобного видеокодирования превзошёл (и с той поры был всегда больше этой нынѣшней величины) ужé изрядно давно. Если не ошибаюсь, то в прошлый раз он был меньше нынѣшняго аж в сообщении >>197092 (то есть 21 ноября 2022 года, чуть больше года назад). Каких-то разительных измѣненій качества кадров (по замѣтности подобных упоминаемым в сообщении >>202666, напримѣръ) я не увидал. Полученный видеофайл может быть (впервые в этом году) помѣщёнъ на 410чанѣ со звуком, но только если наперёд снизить битрейт Opus (указуемый в FFmpeg) до 7k. Результат прилагаю, но берегите уши. 🙉 Как всегда вижу, что если замѣнить Opus на USAC, то результат не рѣжетъ уши, но и не может быть помѣщённымъ на 410чанѣ до тѣхъ поръ, пока FFmpeg не научат пусть не декодировать, но хотя бы распознавать звук USAC по-человѣчески, а не бросать ошибку.
Теперь поговорим о конкурентах AV1. График >>202746 сообщает, что реальным конкурентом для AV1 в настоящее время является только формат VVC (H.266), кодировщик которого в 2021 году (когда создавался этот график) способен был обеспечить соѿношеніе качества и объёма файла на 10% болѣе выгодное, чѣмъ достигаемое в AV1 кодировщиком SVT-AV1. Однако у новости https://news.ycombinator.com/item?id=38554281 появился 9 декабря комментарий (по его собственному адресу https://news.ycombinator.com/item?id=38585361 доступный для ѿдѣльнаго чтения), автор которого утверждал (скриншот прилагаю), что явится ещё болѣе новый формат FVC (H.267) и обеспечит собою такое соѿношеніе качества и объёма файла, которое будет ещё на 10%—30% болѣе выгодным. Может ли кто-нибудь отыскать в Интернете тот первоисточник, из которого этот человѣкъ почерпнул свои свѣдѣнія, или мы должны счесть их бредятиною чокнутого? — вот вопрос.
>>204861 Быстрый гуглинг показал, что: 1. FVC — это альтернативное название для H.266, а не H.267; либо ты не так понял пунктуацию того автора, либо это действительно «бредятина чокнутого». 2. Стандарта H.267 ещё не существует, как и какой-либо внятной информации о нём, а все немногочисленные его упоминания, которые можно найти, — какие-то спекуляции левых людей. 3. Существует хотя бы один человек (https://news.ycombinator.com/item?id=35581416), который утверждает, что текущий рабочий прототип H.267 основан на ECM (https://www.mpeg.org/standards/Explorations/41/). Здесь (https://forum.doom9.org/showthread.php?p=1989706#post1989706) утверждается, что, согласно собранию JVET в Женеве, ECM 9.1 лучше на 30%, чем VTM (Versatile Video Coding and Test Model) 11, на неких тестах. Подтверждений этому найти не удалось, есть только лишь документ (https://www.itu.int/wftp3/av-arch/jvet-site/2022_04_Z_Virtual/JVET-Z_Notes_dG.docx), в котором идёт речь о превосходстве ECM 4.0 над VTM 11. Репозиторий ECM 9.1 доступен по адресу (https://vcgit.hhi.fraunhofer.de/ecm/ECM/-/tree/ECM-9.1).
>>204867 Очень понятно, спасибо. Я предполагаю теперь (руководясь этими находками), что упомянутый выше комментатор был в здравом уме, а элементы его комментария (на скриншоте >>204861) подкрѣплены вот какими обстоятельствами: ① Так как аббревиатура «FVC» означает всего-навсего «Future Video Codec», то возможно использовать её для каждого будущего кодека H.26x-серии, то есть сейчас использовать её для H.267 по той же причине, по которой она использовалася для H.266 прежде (тогда, когда это он был ближайшим будущим кодеком). ② Насколько комментарию https://forum.doom9.org/showthread.php?p=1989706#post1989706 можно вѣровать, настолько и комментарию https://forum.doom9.org/showthread.php?p=1992731#post1992731 также, а там уж упоминание больше 30% превосходства — и даже ещё упоминание рѣшимости достигнуть 60% прежде, чѣмъ выпустить кодек въ свѣтъ. (Что же значит эта рѣшимость? — ѽ, я скажу вам! — означать она может только одно: авторы проекта рѣшилися либо побѣдить AV2 с запасом, либо уж погибнуть отставшими и безвѣстными окончательно.)
Результат исполнения команды «ffmpeg -hide_banner -i исходныйФайл.webm -sn -map_metadata -1 -map_chapters -1 -crf 63 -b:v 0 -c:v libsvtav1 -svtav1-params keyint=0:lookahead=120:tune=0:preset=0:lp=4 -pix_fmt yuv420p10le -strict experimental -c:a libopus -b:a 64k -movflags +faststart -flags +cgop результат.mp4», видео https://youtu.be/puRNQbSMEwo обрабатывающей, в сообщении >>204300 был замѣченъ рѣзко сократившимся в объёме до величины 6 799 678 байтов. Так как приуготавливается версия 1.9.0 движка SVT-AV1, то произошли дальнѣйшія правки исходнаго кода. Табличка вызванных ими измѣненій скорости и качества по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2179 приводится, а объём вышеозначеннаго примѣра сократился ещё далѣе, но ужé не столь разительно — до величины 6 771 921 байта. Получающийся видеофайл может быть помѣщёнъ на 410чанѣ со звуком, но только если наперёд снизить битрейт Opus (указуемый в FFmpeg) до «7.999k». Результат прилагаю, но берегите уши. 🙉 Как всегда вижу ещё, что если замѣнить Opus на USAC, то результат не рѣжетъ уши, но он также не может быть и помѣщённымъ на 410чанѣ до тѣхъ поръ, пока FFmpeg не научат пусть не декодировать, но хотя бы распознавать звук USAC по-человѣчески, а не бросать ошибку. (Правда, даже и тогда придётся дополнительно дожидаться желаемого эффекта, потому что версия FFmpeg на сёрвере 410чана обновится не сразу.)
Если пресет ещё уменьшить до минус первого, то тот же видеофайл увеличивается на 0,55% и достигает объёма 6 809 454 байтов. В этом режиме работы, который только что неслабо разогнали (таблица https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2179 показывает болѣе чѣмъ двукратный рост скорости этого пресета), движок SVT-AV1 жрёт замѣтно больше оперативной памяти: при попытке запустить его тѣми же четырьмя потоками ему хватило восьми гигабайтов, но система Windows кинулась аварийно завершить браузер Firefox и файлообмѣнный сёрвент qBittorrent, чтобы высвободить память. В результате, подумавши над произошедшим, я ограничился двумя потоками и предварительно перезагрузил систему. Получающийся видеофайл также может быть помѣщёнъ на 410чанѣ со звуком, но только если наперёд снизить битрейт Opus (указуемый в FFmpeg) ещё болѣе — до «6.79k». Результат прилагаю, но берегите уши. 🙉 Разница по объёму между нулевым и минус первым пресетом сдѣлалась ≈вполовину меньше той, которая была в мае прошлого (2023) года в сообщении >>201664. Невооружённым взглядом разница качества между пресетами по-прежнему выглядит незамѣтною, однако покадровое сравнение видеофайлов обнаруживает, что воздушный винт над головою второй персонажицы эндинга, неравномѣрно вращаясь, оказывается меньше «размазанным» в фазах быстраго движенія в том случае, когда номер пресета — минус первый.
Руководясь достоинствами минус первого пресета, с августа прошлого (2023) года я начал при сильном сжатии иногда прибѣгать к его помощи, так что къ нынѣшнему времени поднакопил больше 3½ десятков примѣровъ таких сцен, которые кодировал именно минус первым: ① бой в аниме «Engage Kiss» (>>/a/19298), ② Куроюки-химэ передаёт Харуюки приложение Brain Burst, приводит его въ Ускоренный Міръ (то есть в «Accel World», >>/a/19297), ③ Фува Махиро рассказывает о Кусарибэ и их магии в «Zetsuen no Tempest» (>>/a/19312), ④ Такигава Ёщино одолѣваетъ Эванджелин Ямамото и договаривается с нею в «Zetsuen no Tempest» (опять же >>/a/19312), ⑤ «тѣневая болезнь» в «Summer Time Render» (опять же >>/a/19312), ⑥ лѣтній фестиваль смерти в «Summer Time Render» (опять же >>/a/19312), ⑦ батарейки не подходят к пульту управления сплит-системою («Yuru Yuri», сезон 2, пятая серия, >>203700), ⑧ первые 14 минут «Jidou Hanbaiki ni Umarekawatta Ore wa Meikyuu wo Samayou» (>>/a/19323), ⑨ танец лимбо из «Musaigen no Phantom World» (эту сцену я пока ещё использовал только в Телеграме), ⑩ Курогаса оказывает узнан Кэнщином в римэйке «Rurouni Kenshin» прошлого (2023) года (>>203698), ⑪ Сугисаки Кэн сознаётся, что был двоелюбом (>>203697; необходимость термина «двоелюб» по адресу https://t.me/ReadMithgol/781 разъяснялася мною), ⑫ провозглашение Операции Торнадо в «Angel Beats!» (эту сцену я пока ещё использовал только в Телеграме), ⑬ вкус любви в «Dagashi Kashi» (>>203623), ⑭ главная героиня «16bit Sensation: Another Layer» представляется (эту сцену я подготовил для одной из будущих блогозаписей, но пока придерживаю, потому что дропнул это аниме), ⑮ панцу Розетты во втором сезоне «Isekai wa Smartphone to Tomo ni» (>>203750), ⑯ второй эндинг «Asura Cryin'» (>>/a/19413), ⑰ Люси убивает своих тюремщиков и выходит на свободу в «Elfen Lied» (>>/a/19421), ⑱ заключённый №1001 убивает своих тюремщиков и выходит на свободу в «Hametsu no Oukoku» (опять же >>/a/19421), ⑲ Адонис атакует столицу империи в «Hametsu no Oukoku» (опять же >>/a/19421), ⑳ амурский тигр (>>203892), ㉑ взаимосвязь из прошлых жизней в «Denpa teki na Kanojo» (>>/a/19446), ㉒ метеорит ударяет по капищу в «Denpa Onna to Seishun Otoko» (опять же >>/a/19446), ㉓ міръ обретает краски в «Suzumiya Haruhi no Yuuutsu» (опять же >>/a/19446), ㉔ множество красивых одноклассниц в «Chuunibyou demo Koi ga Shitai!» (опять же >>/a/19446), ㉕ первая красавица класса в «Suzumiya Haruhi no Yuuutsu» (опять же >>/a/19446), ㉖ Юки одерживает побѣду над Рёко и спасает Кёна в «Suzumiya Haruhi no Yuuutsu» (опять же >>/a/19446), ㉗ первые полторы минуты «Re:CREATORS» (эту сцену я подготовил для одной из будущих блогозаписей о самоубийствах в аниме), ㉘ чтение BL в «Onii-chan no Koto nanka Zenzen Suki Janain Dakara ne!!» (>>/a/19468), ㉙ первая минута (содержащая и название) кинофильма «The Matrix» (>>/a/19553), ㉚ первые восемь минут первой версии «Ghost in the Shell» (опять же >>/a/19553), ㉛ первые 8½ минут римэйка «Ghost in the Shell 2.0» (опять же >>/a/19553), ㉜ сцена «Log Off» с начальными титрами кинофильма «Avalon» (опять же >>/a/19553), ㉝ напряжённая борьба за благополучное приземление авиалайнера в «Asura Cryin'» (>>/a/19631), ㉞ напряжённая борьба за благополучное приземление авиалайнера в «Hidan no Aria» (опять же >>/a/19631), и ещё двѣ пародии на сцены из «Code Geass», о которых собираюсь сообщить попозже, а сейчас не буду спойлерить. Вы можете видѣть на этихъ примѣрахъ, что к употреблению минус первого пресета я прибѣгалъ в трёх случаях: ➊ Для изрядно длинных сцен видео. Так как для них поневоле приходится значительно повышать CRF (чтобы видео всё же могло как-нибудь помѣститься в ограничение объёма файла), то цѣннымъ оказывается любой рост качества въ этихъ предѣлахъ (даже не очень большой и притом приносимый за счёт неслабого роста времени, затрачиваемого на видеокодирование). ➋ Для изрядно динамичных сцен видео — таких, как эндинг «Asura Cryin'» или оупенинг «Авалона». Причина та же. ➌ Для изрядно коротких сцен видео. Даже кратный рост времени кодирования оказывается в этом случае малозначительным, потому что само это время невелико. Если нѣтъ срочности, то что значит лишний часок-другой?
Много раз слышал, что mkvtoolnix создаёт файлы WebM меньшаго объёма, чѣмъ FFmpeg. Сегодня наконец попробовал на примѣрѣ краткой (≈3½ минуты) видеоцитаты из двадцать первой серии «Sousou no Frieren», засовывая её в 6 мегабайтов (ограничение раздѣла wsg/ на 4chan). Польза mkvtoolnix оказалась в том, что в файл можно засунуть аудиодорожку с незначительно бóльшим указуемым битрейтом (чуть больше ⅔ килобайта разницы). Однако у этой пользы оказалась обратная сторона: в Media Player Classic Home Cinema услыхал очень краткие рѣзкіе перерывы в звуке. Быть может, экономия формата WebM обернулася какими-нибудь проблемами нехватки предбуферизации. Пришёл к выводу, что оно того не стóит и что впредь, как и прежде, буду собирать файлы WebM (из готовой видеодорожки и готовой аудиодорожки) в FFmpeg.
Конкретным результатом оцѣнки выгоды, в сообщении >>206173 упомянутой, сдѣлалася шестимегабайтовая видеоцитата, изготовленная всё же без помощи mkvtoolnix. (Вы можете видѣть её по адресу https://i.4cdn.org/wsg/1708645037918891.webm до тѣхъ поръ, пока она не окажется стёртою ввиду автоматическаго самоочищения Форчана от старых обсуждений.)
Состоявшееся наращивание доступного объёма видеофайлов означает, что теперь я могу создавать пятимегабайтовые MP4, в равной степени пригодные для употребления как на 410чане, так и на сайте Telegraph, братском по отношению к Телеграму. Свѣжесозданный примѣръ (видеоцитату из «Торадоры») прилагаю. По соображениям, недавно изложенным чуть выше, для создания этого примѣра я использовал минус первый пресет, недавно «разогнанный» создателями libsvtav1.
Может показаться, что различие между 5 мегабайтами и 5000 килобайтами не очень значительно, однако в таких граничных случаях, когда создатель видеофайла ужé принуждён к жёсткой экономии, на счету каждая сотня килобайтов. Скажем, видеофайл >>206055 прежде мог помѣститься на 410чанѣ только благодаря тому, что битрейт Opus (указуемый в FFmpeg) понижен был до сверхмалой величины «6.79k». Теперь же (при пятимегабайтовом ограничении) указуемый битрейт звука может достигать величины «10.79k». (Результат прилагаю.) Этот рост величины мы можем и должны счесть болѣе чѣмъ полуторакратным. Результат всё ещё звучит чудовищно по сравнению со звуком USAC (xHE-AAC) равного ему битрейта (попробуйте открыть USAC-версию https://qu.ax/Hreg.mp4 в Google Chrome под Android), однако всё же гораздо лучше по сравнению с предшествующим битрейтом.
Я замѣтилъ также, что в видеофайле >>206387 указуемый битрейт звука может достигнуть и величины «12.0094k» (результат прилагаю), если только при кодировании вызывать FFmpeg с дополнительным параметром «-frame_duration 60». И больше того: хотя в документации https://ffmpeg.org/ffmpeg-all.html есть замѣчаніе «Sizes greater than 20ms are only interesting at fairly low bitrates», я всё же вижу параметр «-frame_duration 60» способным принести болѣе чѣмъ полукилобитную экономию общего битрейта этого файла даже и в том случае, когда указуемый битрейт звука равен 64k. Приходиться всерьёз сожалѣть о том, что прежде я слѣпо руководился этимъ замѣчаніемъ вмѣсто того, чтобы выкрутить значение параметра «-frame_duration» на максимум.
Среди прочих новостей, у меня на Айпаде заработали ВебМ, но, кажется, только ВП8 (в нити ни один файл не открылся).
>>206420 Так как в нити прямо сейчас каждый WebM содержит AV1, то не мудрено: компания Apple поддержку AV1 успѣла обеспечить пока ещё только в самых дорогостоящих своих устройствах (>>203005). Так как между VP8 и AV1 успѣлъ появиться также ещё видеоформат VP9, то можно открыть в архиве https://410chan.org/b/arch/res/156266.html видеофайл https://410chan.org/b/arch/src/160723151925.webm для провѣрки того, работают ли такие видеофайлы WebM, в которых пикселы VP9 тридцатибитны (то есть компоненты цвѣта десятибитны, как это сказано в названии и нынѣшней нити, и указаннаго архива). Нынѣ же приуготавливается ещё один шаг в направлении избавленія міра от тормозов AV1: компания Google задумала поставлять декодировщик dav1d непосредственно в обновлении системы Android, как это по адресу https://www.androidauthority.com/android-update-av1-videos-3420418/ пишут (страховочную копию прилагаю).
Насчёт >>206420 удалось отыскать объяснение того, чего вообще происходит. Оказывается, у компании Apple на прошлой недѣлѣ (5 марта) появилась новая версия 17.4 браузера Safari. Если по адресу https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes открыть список ея новинок и долистнуть до раздѣла «Media» (скриншот прилагаю), то там пишут, что выкатили поддержку формата файлов WebM (и, в частности, поддержку видеоформатов VP8 и VP9, а также формата звука Vorbis) и на iOS, и на iPadOS также. А про звук Opus, между прочим, ничего не пишут. Ну то есть я-то помню, что в сентябре прошлого (2023) года, когда появилась версия Safari 17 без дробной части, тогда по адресу https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes в том же раздѣлѣ («Media») сказано было, что начинается поддержка звука Opus — но только на macOS и почему-то только стереозвука, что было изрядно странно. А съ тѣхъ поръ помалкивают. Может ли быть, что на iOS и на iPadOS не притащили поддержку Opus? Если у кого есть эппловская мобильная техника с новой версиею Safari, то тогда рекомендую провѣрить (как я это ужé в сообщении >>206426 рекомендовал) видеофайл https://410chan.org/b/arch/src/160723151925.webm и откликнуться тут с упоминанием того, видно ли там чего-нибудь и слышно ли. Интересно же.
>>206536 Да, видео и звук работают в файле.
キタ━━━(゚∀゚)━━━!!
FFmpeg обзавёлся поддержкою видеоформата VVC (он же H.266) и вскоре обзаведётся также ещё поддержкою аудиоформата USAC (он же xHE-AAC). То и другое с небольшою задержкою является и в видеопроигрывателях. По адресу https://t.me/ReadMithgol/861 подробности (скриншот прилагаю).
Загрузить версию >>207091 с субтитрами не удалось. Проверка с использованием трюка из >>206374 даёт значения далекие от лимита и одно из них совпадает с отраженным на борде, что также — совпадающе — насчитал и GPT. Т.к. на файловый размер грешить не приходится, вывод — FBE не жуёт встроенные субтитры в webm-контейнер (ошибка 500). Их, впрочем, кажется, не жуют и браузеры в стандартном video-элементе, без сторонних js-плееров, что странно - webvtt прямо для того и придуман чтобы вебм-ки сабить.
Как добавить превью-кадр подсказал Qwen (https://huggingface.co/spaces/Qwen/Qwen1.5-72B-Chat). Рекомендую сию няшу-умняшу, разговаривает на русском, английском, китайском и японском и уж точно поумнее цензурного Яндекса.
Также Qwen сказал, что yt-dlp не имеет возможности автоматически скачать видео, которое было бы не больше определённого указанного размера. И эта информация подтвердилась в GitHub проекта — Qwen был прав. (как видно из скриншота, суть в том, что размер можно задать только, грубо говоря, аудио иди видео дорожке, но не результирующему видео целиком (там на youtube/yt-dlp сложная логика audio-only/video-only кусков и сшивания всего этого...), но это планируется исправить... когда-то) А это, напомню, offline-модель, которая знает только то, что знает, и не может воспользоваться гугло-бингом, отвечая на вопрос. И вот такой вот результат — довольно-таки сугой.
>>207110Мда. Была б у меня осьмушка терабайта ОЗУ... А так - стыдненько. Хоть и впечатлило.
>>207111 Кот-то не так понял? Это же можно использовать бесплатно и безлимитно по ссылке в >>207096.
>>207111 И что же стыдненького тоже интересно.
>>207112Можно. Но кто знает - чего лишнего спрошу али сболтну ненароком - с локальной-то инсталляцией хоть можно обеспечить чисто физически неутечку - а тут - такой-то кус сыра - подозрительно как-то. Представляю примерно во что это по ресурсам обходится ведь. Потрогать что ли младшие модели... Похоже и правда архитектура удачнее, чем Llama получилась.
По адресу https://t.me/ReadMithgol/872 и затѣмъ ещё по адресу https://t.me/ReadMithgol/873 я сообщаю и показываю (на примѣрѣ видеоцитаты >>/a/17579), что у кодировщика SVT-AV1 теперь есть новая настройка («enable-variance-boost=1»), наращивающая качество малоизмѣнчивыхъ кадров видео и малоизмѣнчивыхъ частей кадров. Сшивку скриншотов прилагаю. 💾 Существующее на 410чане ограничение объёма видеофайлов (5 мегабайтов) не позволяет скопировать на 410чан ни один из видеофайлов, содержащихся во втором из упомянутых сообщений в Телеграме. Читателям 410чана, если они того пожелают, нетрудно будет скормить URL сообщения в yt-dlp для самостоятельного скачивания видеофайлов. Но не забудьте про параметр «--restrict-filenames» в командной строке, без которого yt-dlp почти всегда пытается сохранять весь текст сообщения внутри имени скачиваемых видеофайлов (что заканчивается неприятною неудачею такой попытки).
С настройкою >>207375 я попробовал повторить эксперимент >>206387 и >>206400, но ужé на первом шаге получил видеофайл объёмом 9 023 510 байтов, который, уж конечно, никаким уменьшением битрейта звука затащить на 410чан не получится.
Ту же настройку (>>207375) по адресу https://t.me/ReadMithgol/894 я разсмотрѣлъ на примѣрѣ первой из видеоцитат >>/a/19809. Скриншот своих выводов прилагаю. Кто не пожелает зайти в Telegram за архивом результатов, для тѣхъ https://files.safe.waifuhunter.club/4g9WY1jrGfrE7enq.7z
Близится новая версия кодировщика SVT-AV1, отличающаяся другим расположением графика пресетов в той системе отчёта, в которой горизонтальная ось означает время (с логарифмическою шкалою), а вертикальная — Bjøntegaard-дельту (прирост битрейта при равном качестве видео).
В сообщении >>207691 я пишу «близится новая версия», но и сейчас (когда ея выпуск не состоялся ещё) можно же использовать ту версию, которая ужé есть и которая на приложенном графике названа «RC» (то есть предвыпускною). Этой-то нынѣшнею версіею (но без настройки >>207375, чтобы ненароком не получить результат >>207434 или аналогичный) я повторил эксперимент >>206055. Получившийся видеофайл достиг объёма 6 741 265 байтов. Сперва может показаться, что достигнута серьёзная экономия битрейта, раз уж в эксперименте >>206055 получившийся видеофайл достигал объёма 6 809 454 байтов, а теперь явно меньше. Но экономия эта вызвана только тѣмъ одним, что я руководился рассуждениями >>206400 и с сáмого начала поставил настройку «-frame_duration 60» при создании звуковой дорожки. Засунуть же результат на 410чан удаётся только при уменьшении указуемого битрейта звука до величины «11.9k». (Результат этого прилагаю.) Слѣдовательно, по сравнению с результатом >>206400 приходится признать битрейт видео подросшим (потому что битрейт звука видим снизившимся при том же пятимегабайтовом суммарном объёме видеофайла) примѣрно на десятую долю килобита в секунду. Другие возможные причины я испытал и опроверг: ① Теоретически возможно вообразить, что измѣненіе битрейта могло быть вызвано меньшею эффективностью нового FFmpeg при создании файлов WebM. Но я только что (в новом FFmpeg) перегнал результат >>206400 из WebM в WebM (без внесения потерь, простым копированием звуковой дорожки и видеодорожки) и получил 5 222 314 байтов вмѣсто прежняго объёма 5 222 354 байтов, то есть налицо даже сорокобайтовая экономия. По величине эта экономия малозначительна, но по её смыслу можно считать опровергнутым провѣряемое предположение: эффективность создания файла-контейнера не уменьшилася. ② Теоретически возможно вообразить, что измѣненіе битрейта могло быть вызвано меньшею эффективностью нового FFmpeg при создании звука Opus. Но я только что наложил звуковую дорожку, из результата >>206400 взятую «как есть», на видео из прилагаемого здѣсь видеофайла — в итоге получил 5 244 492 байта. Слѣдовательно, можно считать опровергнутым провѣряемое предположение, раз уж прежняя аудиодорожка реально крупнѣе нынѣшней, а не оказалася болѣе эффективною в хранении звука в равном объёме.
Под влиянием графиков https://i.redd.it/jffu6b2nplx41.png я рѣшился опробовать параметр «best» при создании видео VP9. По адресу https://t.me/ReadMithgol/904 изложил свои первые выводы. Скриншот прилагаю.