[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 194168)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5120 кБ.
  • Ныне 3538 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 375
No. 194168  
Начатое в декабре позапрошлого (2020) года сообщением >>156266 погружение в подробности видеокодирования тридцатибитных пикселов принуждено было завершиться опосля 375 бампов.

Здесь — слѣдующая серія.
88 сообщений пропущено. Показаны 50 последних сообщений
No. 198030  
>>197934
Нет, спасибо, лучше дебоширить с сородичами.
No. 198032  
загрузка.png - (0.96MB, 1042×651)
198032
>>198030
Ну, дело ваше. Теперь осталось выяснить, зачем вы дерейлите тред порожним трындежом. Только не говорите, что хотели как лучше, ― как хотели, так и получилось.
No. 200265  
Использовал понедѣльничную сборку FFmpeg для того, чтобы пересоздать видеоклип >>197418 свѣжею версиею libsvtav1.

Получилося в точности 5 120 000 байтов (при CRF 59 и указании битрейта 44,82 kbps для Opus). Результат прилагаю.

По-прежнему ключевые кадры дичайше распадаются на макроблоки, что считаю багом SVT-AV1 и досадую о нём.
No. 201302  
Постоянные читатели этой нити обсуждения успѣли, уж конечно, замѣтить, что всѣ, всѣ послѣднія тестовыя попытки закодировать видеоролик «Basu bango yonbyakujuu バス番号四百十 ED FULL» (в обратном хронологическом порядке это попытка >>197255, до неё >>197092, https://410chan.org/b/arch/res/156266.html#194080 и затѣмъ ещё болѣе раннія, упомянутые в третьем абзаце этого заархивированнаго сообщения) приводили в итоге к тому, что видеофайл не только упирался в 5000килобайтовый предѣлъ объёма, свойственный 410чану, но и превосходил этот предѣлъ собою, даже когда сразу два ужасных крайних средства использовалися для большего сжатия:

➊ даже когда экономия на объёме ключевых кадров дошла до того, что видео вообще не содержало ключевых кадров, необходимых для перемотки назад или вперёд зрителями, так что оно могло воспроизводиться только от начала и послѣдовательно,

➋ даже когда я чрезмѣрно снижал битрейт звука, чтобы дать видео больше мѣста за счёт звука, всё же дѣло доходило до необходимости снизить его так сильно, что звук в формате Opus при таком битрейте звучал очень скверно, и только звук в формате USAC (он же xHE-AAC) ещё как-то справлялся, но видеоролики со звуком в этом формате отклоняются движком FBE (не принимаются къ размѣщенію на 410чанѣ), потому что FFmpeg не способен опознавать их.

И что же было первоначальною техническою причиною этого? — в сообщении https://410chan.org/b/arch/res/156266.html#186737 я замѣтилъ и повѣдалъ (ещё въ іюлѣ 2022 года), что причиною был тот рост качества видео AV1, который был достигнут разработчиками кодировщика SVT-AV1 одновременно с ростом битрейта, так что съ тѣхъ поръ совмѣстно дѣйствовали вот какие четыре обстоятельства:

① возросло качество видео AV1,

② но для обеспéчения этого качества возрос и битрейт,

③ но качество возросло сильнѣе, чѣмъ битрейт, так что Bjøntegaard-дельта (характеризующая соѿношеніе качества и объёма видео) перемѣнилася благоприятно,

④ но всё же возрос битрейт, так что такие видеозаписи, которые кодировалися на предѣлѣ возможных значений CRF (а именно при CRF=63), дальше ужаты тѣмъ же способом (то есть увеличением CRF) быть не могут.

Так как это продолжается болѣе девяти мѣсяцевъ (съ іюля прошлаго года), то поневоле приходится думать, что нам это навѣчно.

Почти немедленно такое положение дѣлъ было осознано разработчиками кодировщика SVT-AV1, так что въ том же іюлѣ по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1946 появилася замѣтка о том, что хорошо бы было реализовать какие-нибудь такие настройки, посредством которых даже при CRF=63 можно было бы видеопоток ещё доужать, то есть ещё немного пожертвовать качеством во имя экономии битрейта (и, слѣдовательно, экономии объёма видеофайла).

Но это пожелание ожидала судьба большинства благих пожеланий, так что съ 13 іюля оно висит там безъ послѣдствій (на этой недѣлѣ в четверг, то есть завтра, исполняется ровно девять мѣсяцевъ, как оно там висит).
No. 201303  
Однако же ход мыслей, мною пересказанных под конец сообщения >>201302, выглядит совершенно правильным.

Дык что ж с того? — а вот что: пусть даже предложенные идеи новых настроек не были никогда реализованы, всё равно можно же поискать и найти среди прежних настроек кодировщика SVT-AV1 такие настройки, которые позволили бы, не трогая значение CRF (упёршееся в свой предѣлъ), всё же ещё сильнѣе ухудшить качество видео во имя экономии битрейта (и, слѣдовательно, экономии объёма видеофайла).

И поискал, и нашёл.

В телевизорах, основанных на электронно-лучевых трубках, болѣе половины вѣка горизонтальная чёткость оставалась хреновенькою, так что во многих стандартах видеозаписи предусматривается возможность записывать видеокадр сплюснутым по горизонтали (для экономии количества пикселов), а затѣмъ растягивать при воспроизведении (примѣры таких стандартов я только что перечислил по адресу https://t.me/ReadMithgol/614 на моём канале в Телеграме, а на 410чанѣ перечислять их не буду: объём текста и без того оказался настолько значительным, что сообщение >>201302 поневоле пришлось закончить, а затѣмъ начать новое, нынѣшнее).

Исключением из этого-то правила сплюснутости не сдѣлался и видеоформат AV1: по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Super-Resolution.md вы можете прочесть о его специальной возможности, предназначенной для горизонтального сжатия кадра (перед кодированием) и растяжения (перед воспроизведением), причём в рамках этой фичи растяжение происходит не внутри видеопроигрывателя, а внутри видеокодировщика, так что утрата визуальной информации частично компенсируется наложением восстанавливающего фильтра (математические подробности этого процесса изложены разработчиками по адресу https://arxiv.org/pdf/2008.06091.pdf въ подраздѣлахъ, обозначенных латинскими буквами VII-C и VII-D).

Предприняв (с параметрами «superres-mode=1:superres-denom=10») кодирование видеоролика «Basu bango yonbyakujuu バス番号四百十 ED FULL», горизонтально сжатого на 20%, я достиг возможности расставить в нём ключевые кадры и поднять указываемый битрейт звука до 31,01 килобита, одновременно умѣстивъ результат в 410чановском 5000килобайтовом ограничении объёма файла. Разсмотрѣвъ этот результат (я его прилагаю), вы обнаружите не очень значительную деградацию качества видео, главным образом проявившуюся исчезновением самых малых звѣздъ со звѣзднаго фона.

Дополнительно обратите внимание и на то, что музыка, использованная автором видеоролика, также ещё прозвучала недавно и по здѣшнему интернетному радио (>>201266), но ужé неусечённою по длине.
No. 201319  
quote.webp - (410.30KB, 1303×4096)
201319
Растровую копию упомянутого выше сообщения https://t.me/ReadMithgol/614 прилагаю для полѣнившихся зайти ко мне на канал.
No. 201664  
Вышла въ свѣтъ версія 1.5.0 кодировщика SVT-AV1 для видеоформата AV1.

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

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

Старый нулевой пресет (новый минус первый) нельзя вызвать параметром «-preset -1» из командной строки FFmpeg (потому что при проектировании этого параметра не предусматривалися отрицательные значения) — но зато можно дописáть (черезъ двоеточіе-раздѣлитель) строку «preset=-1» к значению параметра «svtav1-params» и тѣмъ невозбранно достигнуть желаемого.

Полный список измѣненій подытоживается по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/e32243c0d6ea8fbb6139b1ba7a2e0be9b5da3e18 в репозитории.

По своемý обыкновению я попробовал кодировать https://youtu.be/puRNQbSMEwo при CRF 63 и с указанием 64k в качестве битрейта для звука. Новый минус первый пресет (старый нулевой) оказался работающим ≈впятеро медленнѣе нынѣшняго нулевого пресета (разница между ≈десятью и ≈двумя секундами, затрачиваемыми в среднем на один кадр видео), когда я запустил новый нулевой на трёх двухпоточных ядрах, а затѣмъ минус первый — на одном. (Разница по удѣльной скорости одного потока получается ≈полуторакратною, даже если не принимать во внимание закон Амдала.) При этом разница по объёму файла составила 1,15% (новый нулевой пресет приводит к созданию видеофайла объёмом 6 901 685 байтов, а минус первый — объёмом 6 822 453 байта). Визуально я не замѣтилъ серьёзного снижения качества при переходе на новый нулевой пресет. Кто желает самостоятельно оцѣнить его, для тѣхъ я прилагаю видеофайл, созданный на новом нулевом пресете (но так как 410чан отказывается принять видеофайл вышеозначенного объёма, то пришлось отпилить аудиопоток). Всё это побуждает принять новый нулевой пресет за ту основу, от которой мало мысла уходить к минус первому пресету и тратить много больше времени почти зря.

Версія 1.5.0 кодировщика SVT-AV1 получилась не лишённою недостатков, по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2064 и https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2068 и https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2066 упомянутых. Есть надежда, что разработчики их устранят.
No. 202379  
Измѣненія https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2120 (в исходном коде кодировщика SVT-AV1 совершившіяся) принесли очередной рост скорости: работая пятью потоками, самый медленный (нулевой) пресет видеокодировщика успѣваетъ за 44 минуты обработать одну минуту исходного видео.

По крайней мѣрѣ, именно так он проявил себя на видеоцитате из «Орэгаиру», которую я изготовил во избавление от сожаления, въ послѣднемъ из абзацев сообщения >>>>202364 изложенного.

Видеоцитату прилагаю.

По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2085 видно, что новая быстроходная версия кодировщика глючит въ нѣкоторыхъ режимах работы, выдавая псевдослучайные результаты.
No. 202452  
К версии 1.6 кодировщик SVT-AV1 подходит без проблемы, въ послѣднемъ абзацѣ сообщения >>202379 упомянутой — однако же тот объём файла, который в сообщении >>201664 насчитывал 6 901 685 байтов, теперь равняется 6 946 386 байтам.

Кто желает самостоятельно оцѣнить качество, для тѣхъ я прилагаю этот видеофайл, на новом нулевом пресете созданный — но так как 410чан отказывается принять видеофайл вышеозначенного объёма, то поневоле пришлось отпилить аудиопоток.
No. 202665  
screenshot.webp - (73.74KB, 1280×840)
202665
По адресу https://old.reddit.com/r/AV1/comments/14wz8ib/svtav1_git_the_experimental_ssim_rd_tune_in/?sort=new читал (скриншот прилагаю) впечатления попробовавших экспериментальную новинку кодировщика SVT-AV1, на этой недѣлѣ появившуюся: возможность использования метрики SSIM (вмѣсто PSNR) при внутренней оцѣнкѣ величины потерь, вносимых видеосжатием.

(Вы можете заглянуть по адресу https://en.wikipedia.org/wiki/Structural_similarity и https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio для того, чтобы напомнить себе опредѣленія SSIM и PSNR.)

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

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

Много думал.

Второе из вышеозначенных впечатлений означает, что в случае новой настройки не так остро начинает выглядѣть проблема недостижимости небольших битрейтов (то есть проблема того, что вообще можно сдѣлать, если при максимальном значении CRF видеофайл всё ещё получается больше, чѣмъ хотѣлось бы) — проблема, осознанная разработчиками больше года назад, как это по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1946 видно.

Сам я эту проблему обходил (три мѣсяца назад, >>201303) посредством наращивания горизонтальной сплюснутости видеокадра, которая небезпроблемна, поскольку искусственно снижает чёткость (особенно жестоко обходится с однопиксельными точками — в частности, со звёздами на небе), так что будет очень хорошо, если можно будет обходиться без этого послѣдняго средства.

Ужé вчера (въ понедѣльникъ 17 июля) я обзавёлся сборкою FFmpeg, содержащею новую версию libsvtav1, и тогда самостоятельно попробовал тот эффект, который выбором метрики SSIM обеспечивается.
No. 202666  
Совершив ту пробу, о которой въ послѣднемъ абзацѣ сообщения >>202665 заговорил, я сообщу о достигнутых результатах.

Тот объём видеофайла, который в сообщении >>201664 насчитывал 6 901 685 байтов, а в сообщении >>202452 дошёл и до 6 946 386 байтов, опосля перенастройки на SSIM изготавливается равным 6 110 583 байтам (то есть на 12% меньшим).

Это доужатие позволяет вдругорядь выложить «Basu bango yonbyakujuu バス番号四百十 ED FULL» на 410чан съ болѣе-менѣе нормальным звуком (30,80k задаваемого в FFmpeg битрейта Opus) при условии замѣны контейнера на WebM — и выкладываю.

Битрейт этот приблизительно сопоставим с прошлогодним результатом https://410chan.org/b/arch/res/156266.html#185746 с той разницею, что прошлогодний видеофайл всё же содержал нѣкоторые явные баги видеокартинки, предположительно вызванные ошибкою (или внутреннею недонастройкою) в кодировщике SVT-AV1 и выглядевшие тогда как яркие квадратики вокруг ярких звёзд на нарисованном небе. (Сравнение с результатом https://410chan.org/b/arch/res/156266.html#186742 показывает, что эта ошибка или недонастройка была исправлена ужé к июлю прошлого года, но цѣною рѣзкаго роста битрейта, который только теперь получается одолѣть перенастройкою на метрику SSIM.) Нынѣшній же результат содержит обыкновенные эффекты переужатия, выглядящие как подзамыливание наиболѣе подвижных кусков картинки. Это подзамыливание досадно своею замѣтностью, но всё же терпимо в сравнении с величиною состоявшегося доужатия на 12% или в сравнении с той величиною повреждения наиболѣе мелких и динамических элементов видео (прежде всего тонкоконтурных пляшущих сѵмволовъ над головами у персонажей и персонажиц, а затѣмъ ещё и летящей листвы), которая в сообщении https://410chan.org/b/arch/res/156266.html#175216 наблюдалася при использовании libaom-av1 (то есть до моего перехода к использованию SVT-AV1) и была в два-три раза значительнѣе теперешней.

Если не подавлять формирование ключевых кадров, а расставить их с интервалом 20 секунд, то тогда объём видеофайла возрастает до 6 551 377 байтов. Если дополнительно использовать CRF 62 (вмѣсто CRF 63), то тогда объём видеофайла ещё возрастает до 7 735 905 байтов. Величина этого дополнительного возрастания болѣе существенна, чѣмъ ѿмѣчавшегося в сообщении https://410chan.org/b/arch/res/156266.html#185747 по отношению к прошлогоднему результату, так что эти новые результаты на 410чан затащить не получится, в отличие от прилагаемого.
No. 202866  
screenshot.webp - (268.30KB, 888×1839)
202866
По адресу https://t.me/ReadMithgol/711 я прибавил (скриншот прилагаю) рассказ о том, что в остальном результаты, переходом на метрику SSIM достигаемые, мало меня способны порадовать.

💾 Существующее на 410чане ограничение объёма видеофайлов (5000 килобайтов) не позволяет скопировать на 410чан один из видеофайлов, содержащихся в упомянутом сообщении в Телеграме. Читателям 410чана, если они того пожелают, нетрудно будет скормить URL сообщения в yt-dlp для самостоятельного скачивания видеофайла. Но не забудьте про параметр «--restrict-filenames» в командной строке, без которого yt-dlp почти всегда пытается сохранить весь текст сообщения внутри имени скачиваемого видеофайла (что заканчивается неприятною неудачею такой попытки).
No. 202889  
smush.webp - (0.98MB, 1280×6701)
202889
По адресу https://t.me/ReadMithgol/721 я разсмотрѣлъ ожидаемыя достоинства той новой версии кодировщика SVT-AV1, которая завтра ожидается в новой сборке FFmpeg для Windows.

Сшивку скриншотов прилагаю.
No. 202892  
screenshot2.webp - (282.37KB, 888×1853)
202892
Тот объём видеофайла, который в сообщении >>201664 насчитывал 6 901 685 байтов, а в сообщении >>202452 дошёл и до 6 946 386 байтов, опосля перехода к новой версии кодировщика (в сообщении >>202889 разсмотренной) составил 6 948 876 байтов, то есть стал больше на 0,04%.

По адресу https://t.me/ReadMithgol/725 я думаю, что этим можно пренебрегать. (Скриншот прилагаю.)
No. 202898  
dokuro.jpg - (14.46KB, 480×360)
202898
>>202889
>Microsoft Windows
No. 202899  
>>202889
>Microsoft Windows
No. 202904  
>>202898
>>202899

Просто ещё раз перечитайте окончание прошлогоднего сообщения >>194319.
No. 202905  
1616600780559.jpg - (240.80KB, 1688×1904)
202905
Меня по правде всегда удивлял вопрос: "почему ты используешь операционную систему Х?" Такой вопрос подразумевает, что человек использует ровно одну операционную систему, и больше ничего, что по меньшей мере странно. ОС — инструмент, у разных ОС свои преимущества и задачи. И пренебрежение к виндовс выдаёт каких-то десятиклассников, которые вчера открыли для себя линукс. В то время как разработчик-профессионал скорее всего вообще гоняет вимы/тмуксы на макоси с такой-то ретиной, ибо всё уже давным-давно крутится в облаках, виртуалках и контейнерах, и как-то фиолетово, с чего именно ты к этой инфре коннектишься. Я думал, что на автобусе аудитория в основном из взрослых дядек-айтишников, поэтому видеть вот такие посты >>202898 >>202899 неожиданно.
No. 202906  
9k=(33).jpg - (15.99KB, 225×225)
202906
>>202905
Виндовс вперед! Виндовс чемпион!
No. 202907  
screenshot.webp - (362.12KB, 888×2315)
202907
К сообщению https://t.me/ReadMithgol/725 (в сообщении >>202892 упоминавшемуся) я прибавил, вослѣдъ постскриптуму, ещё и постпостскриптум, содержащий разсмотрѣніе эффекта, новинками libsvtav1 оказанного на послѣднюю из видеоцитат >>/a/19298.

Обновлённый скриншот прилагаю.
No. 202908  
faptcha_php.png - (9.71KB, 90×50)
202908
>>202905
> В то время как разработчик-профессионал скорее всего вообще гоняет вимы/тмуксы на макоси с такой-то ретиной

А что это дает?
No. 202939  
image.png - (23.86KB, 460×423)
202939
>>202898
>>202899
Далеко не все люди играют в Arch Linux.
No. 202954  
>>202939
Таки да, некоторые играют в Slackware Linux, а кто-то даже в Debian или Gentoo.
No. 202955  
faptcha_php.png - (8.54KB, 90×50)
202955
>>202954
> играют в Slackware Linux
Таких сейчас совсем мало...
No. 202975  
7a8d442875c0330b18cf73c06714790f.jpg - (154.06KB, 1270×1700)
202975
>>202954>>202955
Одна девочка NixOS....
No. 202976  
>>202975
Хорошая девочка!
Другая игродевочка решила тоже потыкать NixOS на сервере в скором времени, может, будет пуни-пуни!
No. 202978  
faptcha_php.png - (9.00KB, 90×50)
202978
>>202975
Другая девочка может тоже бы, но опасается длительной настройки.
No. 203005  
A17 PRO - AV1 decoder.webp - (487.46KB, 3840×2160)
203005
Эппловские чипы A17 PRO будут содержать аппаратный декодировщик AV1 для Pro-версий айфонов.

Источник: https://youtu.be/ZiP1l7jlIIA
No. 203006  
>>203005
Я не буду покупать.
No. 203734  
screenshot.webp - (131.36KB, 1200×1093)
203734
Файлы WebM на Форчане могут теперь достигать четырёхмегабайтового объёма на большинстве досок.

Пруфлинк: https://a.4cdn.org/boards.json
No. 203794  
>>203734 4чан - говно с cloudflare picasso
No. 203848  
Обоснуй.
No. 203852  
И не только
>Your web browser must have JavaScript enabled in order for this site to display correctly.
No. 204300  
Тот объём видеофайла, который в сообщении >>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 по-человѣчески, а не бросать ошибку.
No. 204861  
screenshot.webp - (42.76KB, 900×342)
204861
Теперь поговорим о конкурентах 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% болѣе выгодным.

Может ли кто-нибудь отыскать в Интернете тот первоисточник, из которого этот человѣкъ почерпнул свои свѣдѣнія, или мы должны счесть их бредятиною чокнутого? — вот вопрос.
No. 204867  
>>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).
No. 204879  
>>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 с запасом, либо уж погибнуть отставшими и безвѣстными окончательно.)
No. 206047  
Результат исполнения команды «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чана обновится не сразу.)
No. 206055  
Если пресет ещё уменьшить до минус первого, то тот же видеофайл увеличивается на 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. Невооружённым взглядом разница качества между пресетами по-прежнему выглядит незамѣтною, однако покадровое сравнение видеофайлов обнаруживает, что воздушный винт над головою второй персонажицы эндинга, неравномѣрно вращаясь, оказывается меньше «размазанным» в фазах быстраго движенія в том случае, когда номер пресета — минус первый.
No. 206057  
Руководясь достоинствами минус первого пресета, с августа прошлого (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'» или оупенинг «Авалона». Причина та же.

Для изрядно коротких сцен видео. Даже кратный рост времени кодирования оказывается в этом случае малозначительным, потому что само это время невелико. Если нѣтъ срочности, то что значит лишний часок-другой?
No. 206173  
Много раз слышал, что mkvtoolnix создаёт файлы WebM меньшаго объёма, чѣмъ FFmpeg.

Сегодня наконец попробовал на примѣрѣ краткой (≈3½ минуты) видеоцитаты из двадцать первой серии «Sousou no Frieren», засовывая её в 6 мегабайтов (ограничение раздѣла wsg/ на 4chan).

Польза mkvtoolnix оказалась в том, что в файл можно засунуть аудиодорожку с незначительно бóльшим указуемым битрейтом (чуть больше ⅔ килобайта разницы).

Однако у этой пользы оказалась обратная сторона: в Media Player Classic Home Cinema услыхал очень краткие рѣзкіе перерывы в звуке. Быть может, экономия формата WebM обернулася какими-нибудь проблемами нехватки предбуферизации.

Пришёл к выводу, что оно того не стóит и что впредь, как и прежде, буду собирать файлы WebM (из готовой видеодорожки и готовой аудиодорожки) в FFmpeg.
No. 206209  
Конкретным результатом оцѣнки выгоды, в сообщении >>206173 упомянутой, сдѣлалася шестимегабайтовая видеоцитата, изготовленная всё же без помощи mkvtoolnix.

(Вы можете видѣть её по адресу https://i.4cdn.org/wsg/1708645037918891.webm до тѣхъ поръ, пока она не окажется стёртою ввиду автоматическаго самоочищения Форчана от старых обсуждений.)
No. 206386  
Состоявшееся наращивание доступного объёма видеофайлов означает, что теперь я могу создавать пятимегабайтовые MP4, в равной степени пригодные для употребления как на 410чане, так и на сайте Telegraph, братском по отношению к Телеграму.

Свѣжесозданный примѣръ (видеоцитату из «Торадоры») прилагаю.

По соображениям, недавно изложенным чуть выше, для создания этого примѣра я использовал минус первый пресет, недавно «разогнанный» создателями libsvtav1.
No. 206387  
Может показаться, что различие между 5 мегабайтами и 5000 килобайтами не очень значительно, однако в таких граничных случаях, когда создатель видеофайла ужé принуждён к жёсткой экономии, на счету каждая сотня килобайтов.

Скажем, видеофайл >>206055 прежде мог помѣститься на 410чанѣ только благодаря тому, что битрейт Opus (указуемый в FFmpeg) понижен был до сверхмалой величины «6.79k».

Теперь же (при пятимегабайтовом ограничении) указуемый битрейт звука может достигать величины «10.79k». (Результат прилагаю.) Этот рост величины мы можем и должны счесть болѣе чѣмъ полуторакратным.

Результат всё ещё звучит чудовищно по сравнению со звуком USAC (xHE-AAC) равного ему битрейта (попробуйте открыть USAC-версию https://qu.ax/Hreg.mp4 в Google Chrome под Android), однако всё же гораздо лучше по сравнению с предшествующим битрейтом.
No. 206400  
Я замѣтилъ также, что в видеофайле >>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» на максимум.
No. 206420  
Среди прочих новостей, у меня на Айпаде заработали ВебМ, но, кажется, только ВП8 (в нити ни один файл не открылся).
No. 206426  
>>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/ пишут (страховочную копию прилагаю).
No. 206536  
screenshot.webp - (102.42KB, 1280×1144)
206536
Насчёт >>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 и откликнуться тут с упоминанием того, видно ли там чего-нибудь и слышно ли. Интересно же.
No. 206538  
>>206536
Да, видео и звук работают в файле.
No. 206796  
キタ━━━(゚∀゚)━━━!!
Удалить сообщение []
Пароль  
[Mod]