Начатое в декабре позапрошлого (2020) года сообщением >>156266 погружение в подробности видеокодирования тридцатибитных пикселов принуждено было завершиться опосля 375 бампов. Здесь — слѣдующая серія.
>>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 изложил свои первые выводы. Скриншот прилагаю.
19 августа (как это по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.2.0 сказано) вышла новая версия (2.2.0) видеокодировщика SVT-AV1. Официальные сборки FFmpeg, её содержащие, у меня под Windows 7 не заработают (по причине, по адресу https://t.me/ReadMithgol/948 изложенной), однако по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/jobs/7616492094/artifacts/raw/ffmpeg.exe есть сборка FFmpeg, употребляемая разработчиками видеокодировщика SVT-AV1 в качестве тестовой сборки — она под Windows 7 работает невозбранно, однако нифигушеньки не понимает параметр «-frame_duration» (пользу которого я в сообщении >>206400 обнаружил), так что я предпочёл этой сборкою не кодировать звук вообще, а добавлять звук позже (пользуясь для того послѣднею из официальных сборок FFmpeg для Windows 7). Этими средствами я повторил эксперимент >>207694 и вижу, что битрейт видео слегка подрос, так что засунуть результат на 410чан удаётся только при уменьшении указуемого битрейта звука до величины «11,199k». (Результат этого прилагаю.)
Шестнадцатые айфоны будут поддерживать просмотр AV1. Подробности: https://t.me/ReadMithgol/1010 Первоисточник: https://www.apple.com/iphone-16/specs/ Сшивку скриншотов прилагаю.
>>208824 А Самсунги?
Как же мне хочется поддерживать AV1...
>>208827 https://old.reddit.com/r/AV1/comments/187gs9e/current_list_of_smartphone_socs_processors_with/ (Нѣкоторыя модели самсунговского Exynos там есть.)
Котят, у кого-то был скриншот или эксель файл с сравнением времени кодирования и результирующего качества какого-то аниме эпизода. Были x264, vp9 и av1, может еще x265, не помню. Командные строчки так же приводились. Оформлено было точно в таблице, но не помню скриншот ли или сам файл. Пролюбил невозбранно. Перерыл все, не могу найти. Подайте бедному на пропитание?
>>209113 > какого-то аниме эпизода YrYr S1E1.
28 октября (как это по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.3.0 сказано) вышла новая версия (2.3.0) видеокодировщика SVT-AV1. В начале ноября я повторил опыт >>208794 с помощью этой версии и убедился, что теперича видеоролик помѣщается в 410чановский предѣлъ объёма (5 мегабайтов) при указании битрейта звука «12.399k» (результат прилагаю), что лучше майского результата, но не намного.
В качестве комментария к >>209391 я сообщаю, что тогда же (в начале ноября) попробовал видеокодирование со включённым параметром «enable-qm=1», но по сравнению с результатом >>209392 не достиг благоприятных измѣненій в объёме файла — как раз наоборот, видеоролик смог помѣститься в 410чановский предѣлъ объёма (5 мегабайтов) только при указании битрейта звука «9.7k» (результат прилагаю). При виде этого я могу немного перевести дух: кажется, достигнутый лѣтомъ 2022 года результат https://410chan.org/b/arch/res/156266.html#186914 (для которого оба уровня матриц квантования были мною обнулены — и минимальный, и максимальный) не оказался плодом невѣрнаго понимания немонотонной зависимости объёма файла от уровней. При повышении уровня видеофайл дѣйствительно распухает сильнѣе в этой области предѣльно высокаго сжатия (CRF=63). В идеале есть смысл попробовать, наряду с тогдашним диапазоном (0—0) и нынѣшнимъ дефолтным (8—15), ещё один или два каких-нибудь промежуточных (0—8? 0—15?) для провѣрки справедливости этого вывода. Но времени видеокодирование займёт много, так что я предпочту спервоначалу дождаться выхода ещё болѣе новой версии видеокодировщика (SVT-AV1 версии 2.4.0) в начале 2025 года (или во второй половине декабря 2024 года, если поторопятся).
Я попробовал VVC. По адресу https://t.me/readMithgol/1081 рассказал о своих впечатлениях и выводах (скриншот прилагаю), а по адресу https://qu.ax/PVwty.266 выложил файл результата.
