Начатое в декабре позапрошлого (2020) года сообщением >>156266 погружение в подробности видеокодирования тридцатибитных пикселов принуждено было завершиться опосля 375 бампов. Здесь — слѣдующая серія.
>>196977 Лол. Adobe Illustrator CS6 вполне неплохо на моём ноуте (которому 10 и более лет) работает. Пикчи рисуются. >>196979 Хех. Ещё можно из буханки хлеба сделать троллейбус, но зачем?
>>196980 > Пикчи рисуются Показывай!
>>196981 Вот например. Используется как иконка Surp-Rise (ВН разрабатывающаяся небольшой командой на снова лежачем чане)
>>196982 Нарисуй, пожалуйста, иконку чизбургера! Вид сбоку.
>>196984 Может если не забуду, то попытаюсь завтра. Пол одиннадцатого уже как-никак.
>>196980 > Adobe Illustrator CS6 Мы же тут о поддержке новых форматов говорим? — ну дык вот: по адресу https://helpx.adobe.com/ru/illustrator/using/whats-new/2022-3.html#av1format сказано (скриншот прилагаю), что поддержку формата AVIF в Illustrator принесли только с мая нынѣшняго (2022) года, это версия Adobe Illustrator 26.3.1.
>>197000 Звучит круто. Пасиб за инфу. Сказал я пряча по стол 3 раза пережатый джипег.
Позавчера пришло то обновление FFmpeg (и в нём обновление libsvtav1), которого я в сообщении >>196902 дожидался. Опробовал я его сперва, по примѣру сообщения >>194080, на видеоролике «Basu bango yonbyakujuu バス番号四百十 ED FULL», который для того вновь по адресу https://youtu.be/puRNQbSMEwo скачал с Ютьюба посредством https://github.com/yt-dlp/yt-dlp и неожиданно увидал, что при равном объёме файла получается немного другое (или иначе расположенное) содержимое — возможно, это нюансы работы болѣе новой версии yt-dlp (или как раз той болѣе новой версии FFmpeg, о которой я сперва заговорил и которою yt-dlp сшивает же видеопоток с аудиопотоком). Съ тѣми же настройками кодирования AV1, которые были в сообщении >>194080 указаны и тогда порождали результат объёмом 6 813 995 байтов, на сей раз я получил результат объёмом 6 787 374 байта. Это позволяет в пятимегабайтовый объём засунуть полученный видеопоток совмѣстно со стереозвуком USAC (он же xHE-AAC), имѣющимъ битрейт 12 kbps. (Попробуйте открыть видеофайл https://take-me-to.space/S3M8QBP.mp4 в Google Chrome на Android, напримѣръ — но только непремѣнно, непремѣнно в наушниках, потому что современные мобильники, как правило, не оборудуются такими хорошими стереодинамиками, какие были ещё у ZTE Nexus 7, или хотя бы такими, какие были ещё у HTC One M9. Вся экосистема отвратительно выродилась.) В конце сентября (когда я сообщение >>194080 сочинял) такой стереозвук в таком объёме файла ещё не был возможным, потому что стереозвук USAC начинается от 12 kbps. Создавая видеовозможности движка 410чана, я принуждён был отказался от загрузки видеофайлов, не понятных для FFprobe — слѣдовательно, о звуке USAC не может быть рѣчи до тѣхъ поръ, пока проблема https://trac.ffmpeg.org/ticket/8411 остаётся в FFmpeg не рѣшённою даже на сáмом начальном уровне (если поддерживать кодирование или декодирование звука USAC в FFmpeg им ещё может реально помѣшать запатентованность кодека, то уж понимать в FFprobe, какой формат звука был в MP4 засунутым, им мѣшаетъ только ложно понятая неприязнь к запатентованным аудиоформатам). Поэтому в 5000-килобайтовый предѣлъ объёма видео на 410чане этот новый видеорезультат может попасть только со звуком Opus на 7½ kbps, для слуха не очень приятным. (Прилагаю его.) Сомнѣнія, въ предпослѣднемъ абзаце сообщения >>196902 изложенные, оказались, к счастью, не совершенно справедливыми, то есть и при параметре «hierarchical-levels=5» слегка снижается битрейт видео (а не остаётся неизмѣннымъ, как было бы в случае его обусловленности одним только параметром «hierarchical-levels=5»), так что можно осторожно надѣяться и на то, что развитие кодека SVT-AV1 за прошедшее время благотворно повлияло на ту Bjøntegaard-дельту, которая получилась бы при настоящем кропотливом сравнении нынѣшнихъ видеопотоков с сентябрьскими (сравнении не на одном примѣрѣ, а на многих). С другой стороны, так как разница в объёме файла составляет доли процента, то и ахнуть от чрезмѣрнаго удивленія нѣтъ никаких оснований.
Тѣмъ временем природа настолько очистилась, что по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2037 разработчики SVT-AV1 дошли до идеи использовать параметр «hierarchical-levels=5» (благотворность которого я не раз упоминал тут) в каждом из предусматриваемых ими пресетов (режимов работы) этого видеокодировщика. Скриншот (объёмомъ 44 444 байта) прилагаю.
>>161586 > почему ж не существует ещё (ни в FFmpeg, ни ѿдѣльно) таких средств или утилит, которые позволяли бы вытащить из видео AV1 очередной ключевой кадр и без внесения дополнительных потерь пересохранить в AVIF? Полгода назад запилили. https://github.com/FFmpeg/FFmpeg/commit/84241e63cf2f3cc8f7d8a19e86b99f5af95d2a64 ffmpeg -i src.webm -ss somewhere_before_the_keyframe -an -c:v copy -f avif -vframes 1 keyframe.avif
>>197129 Спасибо, дык ить я в курсе дѣла (>>185114).
Повторил эксперимент >>197092, на сей раз используя сборку FFmpeg и libsvtav1, доступную съ нынѣшняго понедѣльника. Получил болѣе объёмистый файл, а именно 6 853 654 байта. То есть объём файла вернулся на позиціи, примѣрно сообщенію >>194080 соѿвѣтствующія.
Пока вы тут обсуждаете виртуальные, немодные и немолодёжные вещи, у реальных людей имеется проблема: как мне постить сюда картинки в JFIF?
>>197894 Их можно в ЖПГ переименовать, потому что это тот же самый формат, вроде.
>>197895 Так вроде, или тот же самый?
>>197896 Википедия говорит, что вариант названия.
>>197897 Ну-ка, проверим.
>>197898 Действительно. А почему с оригинальным расширением нельзя, раз то же самое?
>>197899 Видимо, движок не в курсе про это расширение. JPEG в JPG при этом умеет переводить.
>>197894 > вы тут обсуждаете виртуальные, немодные и немолодёжные вещи Вся эта напраслина, которую вы тут на нас возводите, ещё не даёт вам морального права дирэйлить ѳрэдъ, посвящённый видеокодированию, а не вот этому вот вашему. Для обсуждения вопросов о сохранении изображений ещё в мае нарочно было создано обсуждение >>185114. Пожалуйста, идите туда.
>>197912 Если товарищей оставить заниматься никому не нужной фигнёй, они могут начать прикладываться к бутылке и употреблять разные вещества, начнут нести из дома в скупку вещи своих родных, дебоширить, избивать женщин, детей и стариков, мусорить и ломать деревца, короче всячески портить жизнь окружающим товарищам. Как взрослый и ответственный член общества, я не имею морального права оставить этих товарищей на произвол их незавидной судьбы, и потому просто обязан время от времени возвращать их в реальность.
>>197934 Нет, спасибо, лучше дебоширить с сородичами.
>>198030 Ну, дело ваше. Теперь осталось выяснить, зачем вы дерейлите тред порожним трындежом. Только не говорите, что хотели как лучше, ― как хотели, так и получилось.
Использовал понедѣльничную сборку FFmpeg для того, чтобы пересоздать видеоклип >>197418 свѣжею версиею libsvtav1. Получилося в точности 5 120 000 байтов (при CRF 59 и указании битрейта 44,82 kbps для Opus). Результат прилагаю. По-прежнему ключевые кадры дичайше распадаются на макроблоки, что считаю багом SVT-AV1 и досадую о нём.
Постоянные читатели этой нити обсуждения успѣли, уж конечно, замѣтить, что всѣ, всѣ послѣднія тестовыя попытки закодировать видеоролик «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 іюля оно висит там безъ послѣдствій (на этой недѣлѣ в четверг, то есть завтра, исполняется ровно девять мѣсяцевъ, как оно там висит).
Однако же ход мыслей, мною пересказанных под конец сообщения >>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), но ужé неусечённою по длине.
Растровую копию упомянутого выше сообщения https://t.me/ReadMithgol/614 прилагаю для полѣнившихся зайти ко мне на канал.
Вышла въ свѣтъ версія 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 упомянутых. Есть надежда, что разработчики их устранят.
Измѣненія https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2120 (в исходном коде кодировщика SVT-AV1 совершившіяся) принесли очередной рост скорости: работая пятью потоками, самый медленный (нулевой) пресет видеокодировщика успѣваетъ за 44 минуты обработать одну минуту исходного видео. По крайней мѣрѣ, именно так он проявил себя на видеоцитате из «Орэгаиру», которую я изготовил во избавление от сожаления, въ послѣднемъ из абзацев сообщения >>>>202364 изложенного. Видеоцитату прилагаю. По адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2085 видно, что новая быстроходная версия кодировщика глючит въ нѣкоторыхъ режимах работы, выдавая псевдослучайные результаты.
К версии 1.6 кодировщик SVT-AV1 подходит без проблемы, въ послѣднемъ абзацѣ сообщения >>202379 упомянутой — однако же тот объём файла, который в сообщении >>201664 насчитывал 6 901 685 байтов, теперь равняется 6 946 386 байтам. Кто желает самостоятельно оцѣнить качество, для тѣхъ я прилагаю этот видеофайл, на новом нулевом пресете созданный — но так как 410чан отказывается принять видеофайл вышеозначенного объёма, то поневоле пришлось отпилить аудиопоток.
По адресу 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 обеспечивается.
Совершив ту пробу, о которой въ послѣднемъ абзацѣ сообщения >>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чан затащить не получится, в отличие от прилагаемого.
По адресу https://t.me/ReadMithgol/711 я прибавил (скриншот прилагаю) рассказ о том, что в остальном результаты, переходом на метрику SSIM достигаемые, мало меня способны порадовать. 💾 Существующее на 410чане ограничение объёма видеофайлов (5000 килобайтов) не позволяет скопировать на 410чан один из видеофайлов, содержащихся в упомянутом сообщении в Телеграме. Читателям 410чана, если они того пожелают, нетрудно будет скормить URL сообщения в yt-dlp для самостоятельного скачивания видеофайла. Но не забудьте про параметр «--restrict-filenames» в командной строке, без которого yt-dlp почти всегда пытается сохранить весь текст сообщения внутри имени скачиваемого видеофайла (что заканчивается неприятною неудачею такой попытки).
По адресу https://t.me/ReadMithgol/721 я разсмотрѣлъ ожидаемыя достоинства той новой версии кодировщика SVT-AV1, которая завтра ожидается в новой сборке FFmpeg для Windows. Сшивку скриншотов прилагаю.
Тот объём видеофайла, который в сообщении >>201664 насчитывал 6 901 685 байтов, а в сообщении >>202452 дошёл и до 6 946 386 байтов, опосля перехода к новой версии кодировщика (в сообщении >>202889 разсмотренной) составил 6 948 876 байтов, то есть стал больше на 0,04%. По адресу https://t.me/ReadMithgol/725 я думаю, что этим можно пренебрегать. (Скриншот прилагаю.)
>>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 Я не буду покупать.
