Начатое в декабре позапрошлого (2020) года сообщением >>156266 погружение в подробности видеокодирования тридцатибитных пикселов принуждено было завершиться опосля 375 бампов. Здесь — слѣдующая серія.
>My Next Life as a Villainess: All Routes Lead to Doom! >Catarina Claes, the young daughter of a noble family, one day bumps her head and regains memories of her past life as an otaku. It is then that she realizes she has been reborn into the world of the otome game Fortune Lover as the game's villainess who, regardless of what route the player took in the original game, is doomed to be either exiled or killed. In order to avoid these routes that lead to doom, Catarina begins taking countermeasures. This, however, ends up having unexpected consequences on her relations with the other characters of the game's world. Всем привет, я Мицгол, мне 52 года и сейчас я буду кодировать видиво из этого прекраснейшего аниме!
И ты не Мицгол, и я ещё не 52 года прожил (даст Бог, со временем проживу), и кодировать буду другое. Не надо нести хѣрни!
Начнём с того, что по адресу https://www.dailymotion.com/video/xm7oor располагается теперь другое видео — немного не то, которое я скачал 12 июля прошлого (2021) года и съ тѣхъ поръ использовал во всём предшествующем ѳрэдѣ. Новое видео вѣситъ больше (25 939 950 байтов вмѣсто 25 901 136 байтов), длится дольше (на семь сотых долей секунды), использует чуть болѣе низкий битрейт звука (127 kbps вмѣсто 128) и чуть болѣе высокий битрейт видео (на 2 kbps больше, чѣмъ было). Приходится думать, что либо Dailymotion произвёл какую-нибудь перекодировку первоначального файла (возможно, с наращиванием качества той переужатой версии, которая раздаётся вмѣсто оригинала), либо пользователь, загрузивший туда видеомем «You should install Linux», способен был подготовить новую его копию. (Второй вариант представляется менѣе вѣроятнымъ.) Вы можете самостоятельно сравнить прежнюю версию (страховочные копии которой я сейчас по адресу https://take-me-to.space/sXBvQ7Y.mp4 и https://m1.afileditch.ch/XAPepIjSYOUjZXtjOIn.mp4 выкладываю) с новою (рекомендую https://github.com/yt-dlp/yt-dlp для ея скачивания), если кому небезынтересно. Упомянутую в сообщениях >>181780 и >>181782 и >>181783 и >>181790 и >>181791 и >>181828 досадную проблему, то есть наступившую с конца марта отключённость распознавания границ между сценами видео (по рѣзкимъ перемѣнамъ содержимого кадров) и отключённость расставления ключевых кадров в начале сцен, которая болѣе полугода ужасно раздражала, также удалось одолѣть наконец. На сайте https://scenedetect.com/ предлагают превосходный распознаватель границ сцен (PySceneDetect), итог работы которого можно скармливать параметру «-force_key_frames:v» во FFmpeg. Для запуска PySceneDetect достаточно распаковать архив https://github.com/Breakthrough/PySceneDetect/releases/download/v0.5.6/PySceneDetect-0.5.6-win64-portable.zip в пустом каталоге, затѣмъ для надёжности грохнуть в нём ffmpeg.exe (потому что у меня есть свой, болѣе новый, и я не желаю возможности случайно запустить старый FFmpeg вмѣсто него), а затѣмъ подавать команды наподобие вот этой (на примѣрѣ только что упомянутого видеоролика): \путь\к\каталогу\scenedetect.exe -i xm7oor.mp4 detect-adaptive --min-scene-len 10s --threshold 2 list-scenes --filename сцены.csv Погоняв быстрый (а именно шестой) пресет SVT-AV1 при CRF 61, я на примѣрѣ https://www.dailymotion.com/video/xm7oor увидал, что PySceneDetect позволяет экономить чуть болѣе 2% объёма файла, одновременно расставляя почти вдвое больше ключевых кадров: при настройках наподобие указанных в сообщении >>194080 (с той разницею, что «-crf 61» и «keyint=20s») SVT-AV1 ставит 7 ключевых кадров в этом видео, тогда как PySceneDetect (руководясь вдвое меньшим, десятисекундным, ограничением снизу) предлагает 13 ключевых кадров — здѣсь я пишу «почти вдвое больше», потому что, если пренебречь самым первым кадром (которому в любом видео приходится быть ключевым), то разница между 6 и 12 будет ровно двукратною. Это позволяет догадываться (и догадываюсь), что «цѣна кадра» (выражаемая количеством тѣхъ байтов, которые в файле на него затрачиваются) складывается таким образом, что «дешевле» расставить 12 ключевых кадров в начале сцен, чѣмъ шесть ключевых кадров «в случайных мѣстахъ» (которые «случайные» только с точки зрѣнія сюжета видео, а так-то строжайше соѿвѣтствуютъ двадцатисекундным интервалам). Вот насколько выходит «дороже» сдѣлать ключевой кадр из серединного кадра сцены (который в противном случае оказался бы двунаправленно предсказанным по его сосѣдямъ и оттого дешёвым), а не из начального кадра сцены (который в любом случае содержит крупную междукадровую разность и оттого «ужé дороговат»)! Вдвое, вдвое «дороже»!
Сразу скажу ещё, что даже если бы скармливание итогов работы PySceneDetect во FFmpeg (в нашем примѣрѣ рѣчь идёт о значении параметра «-force_key_frames:v "00:00:02.280, 00:00:12.360, 00:00:23.160, 00:00:33.800, 00:00:43.800, 00:00:54.440, 00:01:04.520, 00:01:16.160, 00:01:26.560, 00:01:39.400, 00:01:51.400, 00:02:02.320"», но только безъ тѣхъ пробѣловъ, которые я тут расставил за запятыми для улучшения читаемости и переносимости на новую строку) не приносило собою двухпроцентного выигрыша по объёму файла и даже слегка наращивало бы этот объём, то и тогда использование PySceneDetect могло бы оказаться повадным, так как хорошая расстановка ключевых кадров в начале сцен обладает ещё тремя слѣдующими достоинствами: ① Не возникает «щелчок качества», то есть рѣзкій рост (или, рѣже, снижение) качества кадров «на ровном мѣстѣ» в середине сцены (на сáмомъ дѣлѣ — въ томъ мѣстѣ ея, на которое «случайно» пришёлся равнопромежуточный ключевой кадр) в силу того, что libsvtav1 любит экономить на качестве кадров во всём интервале между началом сцены и ключевым кадром (или наоборот), если этот интервал волею случая оказывается небольшим (не болѣе ≈десятка кадров). ② В видеопроигрывателе команды «перейти къ слѣдующему ключевому кадру» и «перейти к предыдующему ключевому кадру» перестают быть простым средством быстрого проматывания, приобретают дополнительный смысл «перейти къ слѣдующей сценѣ» и «показать сцену заново с сáмого её начала» (причём в точности «с начала», без появления лишних кадров перед её началом и без пропуска кадров попаданием позже её начала при навигации). ③ Как пересохранение ключевых кадров в AVIF без потерь, так и цитирование видеоматериала без потерь (совершаемое вырѣзаніемъ, всегда начинающимся от ключевого кадра) начинает в точности руководиться границами сцен, возможность срѣзать или прирѣзать лишние кадры почти исключается. Я пишу «почти» потому, что примѣръ https://www.dailymotion.com/video/xm7oor состоит из очень небольших сцен весьма динамичной анимации, умаляя эти три достоинства: и «щелчок качества» не так видно в калейдоскопе визуальных впечатлений, и пожелания навигации и цитирования могут приводить к началу такой сцены, которая всё-таки окажется между ключевыми кадрами (так как окажется короче, чѣмъ та предѣльно малая длина, которая параметру «min-scene-len» была указана). В конечном счёте при CRF 61 и нулевом пресете итог кодирования занимает 6 095 175 байтов и оттого не способен помѣститься на 410чанѣ. Повысив CRF на единицу (до 62), при том же нулевом пресете получаю 5 157 539 байтов. Столь значительная (без малого мегабайтовая) реакция на единичное измѣненіе CRF может объясняться, по-видимому, единственно динамизмом содержимого видео. По сравнению с видеофайлом, к сообщению >>194106 приложенным, видим принесённую PySceneDetect экономию объёма; в практическом смысле она обеспечивает собою возможность помѣстить видео на 410чанѣ с указанием ему большего битрейта звука (62,30 kbps вмѣсто 54,89 kbps). И помѣщаю. Во всё это время я испытывал изрядный соблазн не кодировать никакое видео AV1, по меньшей мѣрѣ, до второй половины понедѣльника, то есть дожидаться появления очередной еженедѣльной сборки FFmpeg, в которой движок libsvtav1 ужé содержал бы исправление ошибки (ранѣе в сообщении >>193934 упоминавшейся), замедляющей работу его под Windows. Подсчёты https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2016#note_1119896397 наглядно показывают, что эффект этой ошибки зависит от пресета, возрастая вмѣстѣ с качественностью кодирования видео, так что ≈троекратное (в 2,7 раза) замедление работы седьмого пресета оборачивается ≈шестикратным (в 6,1 раза) замедлением работы четвёртого пресета. Однако же, пренебрегая той тормознутостью, всё же и начал, и закончил всё дѣло ранѣе понедѣльника.
>>194184 >хѣрни Бу. Старый, вредный. А говорит, 50-ти нет! У кого-то есть ссылки на посты, где Мицгол обьясняет, почему он использует Windows? Интересуюсь на фоне очередного (не без улыбки до ушей) просмотра этого видео «Year of the Linux Desktop».
Пишу в подходящий по смыслу тред, ничего? Подскажите, что с этой картинкой, почему она такая огромная и плохо жмётся в тот же самый jpg понижением quality? https://danbooru.donmai.us/posts/5113998 Есть куда более визуально детализованные картинки, занимающие при этом меньше места.
>>194255 cwebp -m 6 -q 92 дает 4.8 мегабайта и качество не то, что бы отличить. mozjpeg -quality 92 дает 4.6 мегабайта, но не позволяет перейти даже к 92.5, буквально чуть-чуть не влазит на автобус: 5,171,076 байт вместо 5,120,000. Результат прилагаю.
Что касается >плохо жмется понижением качества так mozjpeg при качестве 60 уже 806,187 байт, что не может быть расценено как "плохо жмется". Да что там, качество 90,60 выдает 3,408,996 байт, и при этом хрен ты так легко заметишь отличия. И это тоже сложно назвать "плохо жмется".
>>194264 Да, признаю, жал неправильно, видимо, спасибо. Жал просмотрщиком, при 95 он даёт 7.2 MB, при 92 5.9. Почему-то думал, что ниже 95 это уже довольно плохо, ведь ОП треда всё отказывался жать картинки в это качество и настаивал на webp.
А вот что даёт эта штука. Она вообще без настроек.
>>194255 > 24bit N JFIF [OK] 23133086 --> 20797455 bytes (10.10%), optimized Как минимум, она была пожата каким-то старым JPEG-ом. Как максимум, она на самом деле детализованная, а точнее — содержит большое количество шума. Шум особо не пожмёшь.
>>194191 > Мицгол обьясняет, почему он использует Windows? Все таки, в наше время, следует дополнительно объяснять почему используется НЕ Windows. Как линуксоид говорю! А аргументы Мицгола послушал бы с удовольствием конечно, ежели такие вообще имеются.
>>194284 А чей это вывод цитатный?
>>194298 >Все таки, в наше время, следует дополнительно объяснять почему используется НЕ Windows. >Как линуксоид говорю! А казачек-то зас Обоснуй, не понял.
>>194299 jpegoptim --strip-none -o
>>194307 Ну, популярность систем сильно разная. Обычно объяснять приходится почему у тебя основная система не Windows, если речь идет о десктопе. Это и сейчас так ,а в годы становления Мицгола программистом DOS/Windows полностью доминировали везде вообще, вот он и... Я примерно это хотел сказать. ПРИЗЫВАЮ Ув. Мицгола дать развернутый комментарий!
>>194308 >jpegoptim Ты б еще гвоздей поел.
>>194311 >Обычно объяснять приходится почему у тебя основная система не Windows Я говорю "так сложилось исторически" и закрываю тему. В конце концов какая разница, если делаешь свою работу.
>>194313 У меня веб-разработка с позволения сказать, поэтому Linux безальтернативен. Я обычно так говорю. >В конце концов какая разница Бывает спрашивают, зачем это всё.
>>194314 >зачем это всё Все люди этим вопросом задавались, наверное. И я сам не знаю, зачем я есть, в чём смысл жизни, где у мяуколки мурчалка и т.д. Одни ли мы во Вселенной скорее всего да, как работают современные процессоры после Pentium 4 и прочее. Сложные вопросы на Автобусе сегодня задают, ух, серьёзные и сложные.
>>194315 > скорее всего да Тогда и антропный принцип скорее всего верен и бог/боги скорее всего тоже есть. А может действительно, так оно и есть. Дела, однако. P.s. Имеется в виду - в конкретике неясно как работает или даже модель непонятна?
>>194255 > Пишу в подходящий по смыслу тред Нѣтъ. Подходящим по смыслу было бы то обсуждение сжатия (и вообще сохранения) изображений, которое сообщением >>185114 начиналося. > что с этой картинкой Наблюдение >>194284 насчёт шума совершенно справедливо. > Есть куда более визуально детализованные картинки, занимающие при этом меньше места. Значит, их визуальные детали не обладают той степенью непредсказуемости, которою обладает случайный шум. >>194264 > cwebp -m 6 -q 92 >>194266 > настаивал на webp Настаивал и продолжаю настаивать на том, что при сжатии в WebP с потерями мало и не достаточно бывает указывать кодировщику cwebp одно только значение качества. Гораздо лучше одновременно употреблять ещё и тот недокументированный пятый препроцессор (параметр «-pre 5»), достоинства которого продемонстрированы в сообщениях https://410chan.org/b/arch/res/158687.html#164961 и https://410chan.org/b/arch/res/158687.html#164965 в архиве 410чана. >>194267 > А вот что даёт эта штука. По адресу https://trimage.org/ сказано, что для файлов JPEG эта штука служит обёрткою над оптимизатором jpegoptim, занимающимся переужатием JPEG без внесения потерь. Это тот самый оптимизатор, который был использован в сообщении >>194284, назван в сообщении >>194308, беспочвенно обруган в сообщении >>194312. Сборкою послѣдней его версии пользователи Windows могут по адресу https://github.com/XhmikosR/jpegoptim-windows/releases/tag/1.5.0-rel1 разжиться, а пользователи других операционных систем могут по адресу https://github.com/tjko/jpegoptim/releases/tag/v1.5.0 скачать исходный код. > Она вообще без настроек. А их и не надо, просто жмёт по максимуму всегда, да и всё. Так как переужатие не вносит никаких потерь, то этот образ дѣйствій является наилучшим. >>194191 > Мицгол обьясняет, почему он использует Windows? Звуковую дорожку видеофайла, по адресу https://take-me-to.space/qiCpXoH.mp4 расположенного (это тот самый, который по адресу https://t.me/readMithgol/532 прилагался и в сообщении >>194080 упоминался), можно послушать под Windows, если открыть адрес файла в аудиопроигрывателе https://www.foobar2000.org/ (сперва в него компонент https://www.foobar2000.org/components/view/foo_pd_aac установив) и дождаться завершения скачивания видеофайла из Интернета. Расскажите, чѣмъ послушаете её под Linux? (Формат звуковой дорожки — USAC, он же xHE-AAC.) Это лишь первый из десятков вопросов, на которые я не знаю готового ѿвѣта и притом не хочу разводить оффтопик в обсуждении, предназначенном для другой цѣли.
Упомянутая в сообщении >>194188 счастливая возможность использовать https://scenedetect.com/ как средство обнаружения подходящих мѣстъ для расстановки ключевых кадров позволяет (съ тѣми же параметрами для scenedetect.exe) найти их так удачно, что видеоклип https://vimeo.com/210902520 (в сообщении >>188513 лежащий с указанием битрейта звука 58,34 kbps) может быть теперь помѣщённымъ на 410чан с указанием для звука 65,35 kbps при том же CRF=61. Какую-то роль в этом сыграли, должно быть, упоминаемые в сообщении >>194056 оптимизации и исправления в SVT-AV1. Без донастройки битрейта звука и без преобразования в WebM этот видеофайл (кодированный нулевым пресетом) занимает 5 133 069 байтов, а его черновик (тот же файл, но кодированный шестым пресетом для провѣрки, хорошо ли работает перерасстановка ключевых кадров) занимает 6 115 460 байтов, а без помощи PySceneDetect (кодированный тѣмъ же шестым пресетом) занимает 6 154 004 байта. Громадная (без малого мегабайтовая) реакция объёма файла на обнуление пресета не очень для меня понятна.
>>194319 >Гораздо лучше одновременно употреблять ещё и тот недокументированный >лучше >применять >недокументированный Довольный странный ход мысли применять недокументированные функции, но не мне вас программистов судить. >беспочвенно обруган в сообщении >>194312. Не беспочвенно. Lossless JPEG это мусор, а для не lossless херня вроде оптимизации не нужна. И pngoptim тоже гвозди, convert -quality 95 в 80% случаев дает либо такой же, либо неотличимый (по весу) результат. У вас просто шизофрения на почве байтов. >Расскажите, чѣмъ послушаете её под Linux? Таки не послушаем, потому что "not implemented" нигде толком. Но тут таки нужно копнуть глубже. >In April 2016, Via Licensing announced the launch of a xHE-AAC patent pool licensing program for 2016. >In 2018, xHE-AAC was included in Via Licensing's AAC patent pool at no additional cost. >Opus (codec) – a royalty free alternative, low latency codec for a similar usage После чего ответ напрашивается сам собою: проблема создана искуственно. Патентованные кодеки от MPEG — давно пора на свалку. Вот я краем уха слышал, что Fedora отключила vaapi поддержку h264 и hevc, потому что патенты. Сами же себе под двери говна навалили, а теперь репу чешут — как же декодировать? А никак! Нехер было сопутствовать продвижению заведомо вредоносных технологий. Например, у меня под линуксом есть firejail(1), а так же штуки по типу ip-route(8), nft(8) и так далее. А у вас — нет. Мой образ диска не отсылается на сервера Micro$oft, а ваш — регулярно, я знаю, я пользовался, потребление диска было настолько большим и невыносимым, что других выводов сделать просто не получается. А еще у вас нельзя ^Alt+<F1-12> для переключения между виртуальными консолями, что делает работу с несколькими пользователями непрактичной и неудобной. А еще у вас UI — говно откровенное и невыносимое. И при этом у вас нельзя установить i3. Да куда уж там! Возьмите флешку, обыкновенную простую USB флешку, сделайте на ней какую-нибудь MBR таблицу и два раздела. И попробуйте открыть второй из них под Windows. Что же, видимо сходу не получится? И что теперь? Верно, верно, дорогой мой друг — не очень-то и хотелось. Вот и мне не очень-то и хотелось этими ненужными кодеками пользоваться.
>>194321 Репу никто не чешет. H.264 спокойно декодировался и декодируется на любом процессоре, который не говно мамонта. Люди, которые накачали релизов в H.265, накачали их не просто так и либо сменят Федору, которую они себе зачем-то поставили вместо Убунты, на Убунту, Дебиан или Арч, где всё работает, либо будут компелять себе пакеты сами.
>>194319 > Расскажите, чѣмъ послушаете её под Linux? Поставлю кодек очевидно, если из коробки нет. Это как раз простой вопрос.
>>194326 Ну-ну, поставь. А заодно и с нами поделишься, как ты его поставил.
>>194327 > xHE-AAC Проблема осознана в полной мере после 10 минут гугления.
>>194325 >Репу никто не чешет А я — Буратино, ага.
Формально сжатие видео достигло ужé такого уровня, что в 410чанский 5000-килобайтник можно засунуть 3 минуты 50 секунд окончания третьей серии «Ichiban Ushiro no Daimaou» (примѣръ прилагаю), причём единственным реально досадным артефактом сжатия будет «разваливающаяся / подлагивающая катана» на фоне солнечнаго диска на восьмой, девятой, десятой секунде.
>>194327 git clone https://aur.archlinux.org/ffmpeg-libfdk_aac.git makepkg pacman -U *.pkg* Из соображений лаконичности, некоторые промежуточные шаги не упомянуты. Проигрывается mpv.
git clone https://aur.archlinux.org/ffmpeg-libfdk_aac.git makepkg pacman -U *.pkg*
>>194339
По адресу https://telegra.ph/5-megabytes-of-AV1-in-MP4-on-Telegraph-pages-in-2022-08-06 я систематизировал понимание измѣненій в возможностях AV1, произошедших за послѣдніе два года.
По-видимому, дальнѣйшіе эксперименты с использованием SVT-AV1 я принуждён буду отложить до будущей недѣли по двум причинам. Во-первых, как я это по адресу https://twitter.com/FidonetRunes/status/1590031030458929153 ужé упоминал, в настоящее время по адресу https://gyan.dev/ffmpeg/builds/ ясно видно, что сборщик FFmpeg для Windows рѣшилъ сдѣлать перерыв до 21 ноября, то есть как раз до ближайшаго понедѣльника. Во-вторых, с новым FFmpeg должна прийти и новая версия libsvtav1 — а на нынѣшней недѣлѣ к появлению в ней приуготавливаются измѣненія https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2030 (скриншот их описания прилагаю), которые притащат с собою не только рост скорости или качества видеокодирования, но и исправления замѣченныхъ ошибок в логике кодировщика. Не хочется до этого момента тратить завѣдомо больше времени или получать завѣдомо меньше качества. Сразу скажу, что я не готов слишком уж затаивать дух в предвкушении роста качества: легко может оказаться, что изрядная часть достигнутого качества может быть отнесена на счёт того только, что разработчики libsvtav1 наконец распробовали полезный эффект от параметра «hierarchical-levels=5» (тот эффект, который я начал упоминать на 410чане ещё лѣтомъ, как это видно в сообщениях >>185746 и >>185747 и >>185939 и >>186640 и >>186737 и >>187402) и рѣшили теперича примѣнить его ко всѣмъ пресетам от нулевого до шестого включительно. Тогда получится так, что в моих видеоцитатах этот рост качества в полной мѣрѣ совершился ещё нынѣшнимъ лѣтомъ, а новая версия libsvtav1 ничего существенного к этому не прибавит. Впрочем, посмотрим.
У меня на Win7 твои видео воспроизводятся в МедиаПлеере с кодек-паком, но не воспроизводятся в Edge. Как можно это недоразумение исправить?
>>196904 Майкрософтовский браузер — настолько майкрософтовский, что работу AV1 обеспечивает (согласно изложенным по адресу https://caniuse.com/av1 наблюдениям) при двух непремѣнныхъ условіяхъ: ① установите Windows 10 или ещё новѣе, ② поставьте https://www.microsoft.com/store/productId/9MVZQVXJBQ9V из Microsoft Store. Вывод: если желаете оставаться на Windows 7, то достоинства новых видеоформатов обеспечит только какой-нибудь другой современный браузер — Mozilla Firefox, Google Chrome, Opera, etc.
>>196905 А внутрях это тот же самый Хром, вид сбоку. И скорее всего ему можно подсунуть нужный кодек. >если желаете оставаться на Windows 7 Мне работать надо. Так что или сидеть с новыми видеоформатами в браузере, или с деньгами. Это ещё не самый злой прикол вендорских решений.
Если можно запускать TOR нарочно для того, чтобы попасть на Nowere из РФ, то уж конечно можно запускать и Firefox нарочно для того, чтобы видѣть AV1 на 410чанѣ. То и другое разве мѣшаетъ использовать Edge по рабочей надобности?
>>196908 Я сплю и вижу, как бы мне на Новерь попасть, да. И чего-то там ещё нарочно руками для этого каждый раз запускаю. И логины-пароли храню на стикерах, приклееных к экрану ноута — именно потому у меня их уже четыре штуки, что за стикерами экрана не видно. И никуда, кроме Новеря и Автобуса, не хожу, (и из дома не выхожу тоже) и проблем с синхронизацией браузеров на ноутах и мобилах не имею. И то, что мне нужон зоопарк компов, — это чисто моя блажь, а не проблемы идиотов, покупающих всякие ломучие гаджеты (сидели бы как встарь, без компутеров и гаджетов, радиво Маяк слушали бы и понравившиеся передачи на магнитную ленту писали). Иными словами, никакого иного решения, кроме как на каждый смарт-утюг ставить специальный браузер, у тебя нету? И никто его до сих пор не придумал, как придумали отключалку VP9 и AV1 для слишком современных CDN?
Не знаю. Но на всезнание не претендую. (Может быть даже и то, что буйное племя проксисёрверятников ужé додумалось до какой-нибудь перекодировки из AV1 в AVC, совершаемой «на лету», а мне об этом ничего не извѣстно и не может быть извѣстно.)
>>196912 > сидели бы как встарь, без компутеров и гаджетов, радиво Маяк слушали бы и понравившиеся передачи на магнитную ленту писали Так и надо жить, все правильно.
>>196905 > если желаете оставаться на Windows 7 То с Вами что-то не так.
>>196926 Устыдись своей неоплачиваемой пропагандистской работы на одну из богатейших корпораций.
>>196927 Синдром утёнка ни к чему хорошему не приводит.
>>196926 Civilization III нормально запускается только там...
>>196913 Додумалось до того, чтобы отучать клиенты говорить, что умеют в WebP, VP9, AV1. Лучше всего это делается, конечно, средствами локальной прокси — прозрачно для клиентов, — но и через расширение для браузера тоже можно. Людям что надо-то? Чтобы у них Ютуб на нетбуке не тормозил, а какой там кодек, им глубоко наплевать. З.Ы: Держи красивую картинку. >>196918 Истину глаголишь. >>196926 Вероятнее, вы — безработный студент с претензиями у мамки на шее. Ибо у всех остальных к компьютеру появляются определённые требования. У меня тоже так было, потом я устроился на работу и там понадобился планшет с толстой батарейкой, большим экраном/DPI, хорошим GPS-приёмником и картами надо, кстати его попробовать воскресить — он всё-таки топовый был для своего времени, — может для диагностики умных холодильников сгодится. Tl;dr Мы такого студента давеча наняли, чтоб он на приёмке сидел и обезьянкин ремонт всунь/высунь делал, а мы ему зарплату платить будем. Аттракцион неслыханной щедрости, короче. Он за месяц умудрился запороть шлейф от дисплея умных часов, кокнуть новую матрицу от ноута, пасть в неравной борьбе с алисиной колонкой (почему она с нами нормально разговариет и работает?), не суметь подключить потроха от умного дома к смартфону, поменять силовую плату в ИБП, завести ремонты в базу и заполнить отчёты о выполненных работах. Зато на древний кудахтер, который в хламе валялся, поставил Win10 нахрена она там? На приёмку нужен Офис, на прошивки — Win7, так що выбор очевиден, правда активировать не смог. Зато у него профильное образование и паяльная станция, тока почему-то то приборы не диагностируются, то отвёртка крутиться не хочет, то паяльник не паяет, то фен не греет. Мне на приёмке сидеть, конечно, не хочется, но и дело надо спасать, так що последний месяц он тут работает, похоже.
>>196940 Не странно ли это в устройстве общества, что проблема содержания людей почему-то лежит на плечах организаций, которые в общем-то занимаются совсем другим делом?
>>196943 Разве в описываемом случае имеет место содержание?
>>196945 Работа является единственным источником дохода у большинства людей. Хозяин их кормит и может выставить на мороз и голод; может отобрать деньги, если раб плохо сам себя хлестал невидимой мотивирующей плеткой; может делать вид, что не знает что такое "инфляция", никогда не слышал.
>>196948 Так работа это отнюдь не "содержание", этому студенту несчастному не просто так деньги платят, а за то что он там где-то сидит, по крайней мере, и пытается что-то исправить на свою голову. Вот если бы ему просто так эти деньги давали тогда и было бы "содержание".
>>196949 Деньги дают только потому что без этого мясо физически не сможет на эту работу притащиться в более-менее приличном виде. А так бы и не давали. В любом случае социальные функции лежащие на работодателе имеются.
>>196926 С теми кто бездумно обновляет всё что видит что-то не так. Да и объективно, семёрка отличная система для повседневного использования да и не только для этого. >>196940 >студент поставил на старый комп десятку. Это ещё ладно когда такое студент делает. У нас препод по архитектурам аппаратных средств однажды на не самые новые и достаточно слабые компы поставил виндовс 11 (а ещё параллельно бубунту воткнул). Не сложно догадаться к чему это привело. Обоснование сего действа максимально эпичное: "ну типо десятку прекратят поддерживать и в ней начнут плодиться незалатанные дыры" (при этом роутер на котором держится локалка в кабинете (а может и не только в нём) не запаролен и имеет выход во внешний интернет, лол)
>>196951 Боюсь обсуждаемый нами работодатель этого ни в малейшей степени не осознает, его это мало волнует в принципе. >Деньги дают только потому... Вообще-то так и есть конечно, по гамбургскому счету, платят минимум возможного.
>>196952> Да и объективно, семёрка отличная система для повседневного использованияТочно также про XP говорили 6 лет назад, пока под него был хотя бы официальный Firefox ESR.
>>196940 По субъективному представлению этого студента win7 это наверняка седая древность, на которую и смотреть то опасно. Для его поколения характерны такие предубеждения, глупые конечно.
>>196940 410чан — не Ютьюб и даже не CDN: нельзя сказать 410чану, что браузер не тянет AV1, и ожидать того, что соусовский «Супермаркет» волшебным образом обернётся транснациональною межконтинентальною жидокорпорациею и потратит малую толику многотриллиннодолларовой прибыли на автоматическое и заблаговременное создание самых разных версий видеоролика, одну из которых скушает ваш утюг, ваш кофейник, ваш паяльник, ваш пробойник, ваш студентик, ваш холодильник, etc. Вам ясно намекнули русским языком, что Корпорация Microsoft мѣшаетъ пользователям Windows 7 смотрѣть видео AV1 во браузере Edge? Вы предпочли в сообщении >>196907 не понять намёка и вмѣсто того сдѣлать вид, что Microsoft ни при чём и во всём бѣломъ, и что других браузеров не бывает для Windows 7 или лучше бы их не было, и что тутошний создатель видеороликов AV1 (даже если сам сидит именно под Windows 7 в Файерфоксе, и хорошо себя чувствует, и на скриншоте >>196905 только что лично именно это показал) — нехороший злой человѣкъ, который хочет понудить к обновлению Windows и помѣшать зарабатывать деньги? Вы в сообщении >>196912 сардонически иронизируете сарказмом, а смысл его смутно сводится к тому, что обладаете таким обширным зоопарком компóв, ноутов, мобил и даже смарт-утюгов, что одна только попытка запустить вмѣсто Edge (который не умѣетъ AV1 под Windows 7) какой-нибудь другой браузер (который умѣетъ AV1 под Windows 7) создала бы проблемы с синхронизацией браузеров? Во-первых, выглядит это очень странно. Вы ж не пояснили, откудова возьмутся эти проблемы. Во-вторых, а у этих проблем точно нѣтъ какой-нибудь такой обратной стороны, которая сводится к тому, что на одном из этих устройств установлена не «семёрка», а поверх несемёрки — ещё и не Edge? Точно-точно? А не то, знаете ли, мобильный Chrome ещё в марте прошлого (2021) года обзавёлся поддержкою AV1, по адресу https://old.reddit.com/r/AV1/comments/lwtstm/chrome_89_released_with_dav1d_081_and_avif/ упоминаемою в комментариях, так что давно способен показывать AV1 на 410чанѣ. А если кого с души воротит от мобильного Хрома, то и бета мобильного Файерфокса также очень ok. Кроме того, попытка сформулировать и отстаивать идею «всѣмъ, кто работает, опредѣлённо требуется система Windows 7, а поклонниками Windows 10 становятся только безработные студенты» выглядит очень странно под конец 2022 года. Рассмотрим, напримѣръ, создавшееся положение тѣхъ граждан, которые зарабатывают себе на жизнь программированием. Новые версии Python не работают под Windows 7. Новые версии Node не работают под Windows 7. Новые версии Qt не работают под Windows 7. Этот список можно и дальше продолжить. Граждане, рѣшившіе видеовѣщать, сталкиваются съ тѣмъ, что новые версии OBS не работают под Windows 7. Граждане, рѣшившие чего-нибудь скачать по файлообмѣну, сталкиваются съ тѣмъ, что qBittorrent ясно объявляет по адресу https://www.qbittorrent.org/news.php о том, что поддерживает работу новых версий под Windows 7 дольше, чѣмъ обѣщано (а обѣщано было только до лѣта 2022 года). И такъ далѣе.
>>196961 Не говоря уже про протухшие корневые сертификаты в MSDN-образах семёрки 2011 года, которые можно найти на торрентах (при этом скачанный при помощи Fido.ps1 образ семёрки имеет заплатки по июль 2018, рабочие сертификаты и Windows Update).
Ах, ну зачѣмъ же было проблемки >>196964 вообще упоминать. Сейчас начнётся новая серия догадок о том, кто тут «безработный студент с претензиями у мамки на шее» и оттого не заработал на лицензионный Windows 7, а кто, в свою очередь, занялся «своей неоплачиваемой пропагандистской работой на одну из богатейших корпораций».
Дружелюбный напоминатель напоминает, что нетбук, спокойно поддерживающий ШИНДОШС 10 и декодирование 4k AV1 стоит всего 1 МРОТ. https://avito.ru/moskva/noutbuki/hp_elitebook_8470p_2674773014
>>196968 >HP Elitebook 8470p >Ноутбуки HP EliteBook по цене от 85700 Там нолик забыли приписать. И да, прекрасно знаю я эти ноутбуки с окошками 10 и современными возможностями декодирования. Покупаешь такой по дешёвке, а там 2 GB RAM, на которых десяточка еле запускается тормозит и сжирает всю нагрузку и память. Я даже не удивлён почему по твоей ссылке указали видеокарту, но не указали конкретную мать.
>>196970 ЖИРНО. Я сам на таком эти 10 лет отсидел, и 4k AV1, которое Мицгол тут было постил, там проигрывалось на ура. Одно ядро IvyBridge i7 лишь в 2 раза слабее ядра ZEN3 Ryzen7. Модель платы там указана, кстати. На одной из картинок. У дна крышка на защёлках, и при желании можно хоть 32 GiB DDR3 с лёгкостью запихать.
>ЖИРНО! НЕТ! Девочки, хотите жить достойно, не верьте этой >>196971 девочке. Адепты десяток+ превратят вашу жизнь в неоптимизированный ад. И ничего с лёгкостью в ноутбуки не запихивается даже при всём желании - потом сожжёте себе стол вместе с квартирой и всей вселенной. Если берёте себе ноутбук с 10/11-очкой то сразу готовую укомплектованную сборку с адекватным закрытым корпусом и соответствующей продуманной вентиляцией, с минимум 8 GB RAM. Не продешевите и будьте осторожны с б/у, особенно когда дело касается ноутбуков.
В наше время ноутбук с ценником меньше 130-150к - мусор. Ну ладно, меньше 100к. Но это прям совсем нижний предел. Дешевле просто смысла никакого не имеет брать, потому что телефон с теми же задачами справится лучше.
>>196973 >телефон с теми же задачами справится лучше. Позволь поинтересоваться, как ты Adobe illustator c Th6/7/8 на телефоне запускать собрался? >>196972 > Адепты десяток+ превратят вашу жизнь в неоптимизированный ад. Плюсую. > И ничего с лёгкостью в ноутбуки не запихивается даже при всём желании FreeDOS вроде отлично без мыла встаёт так-то проверял.
>>196975 А что ты с Adobe Illustrator на дешёвом немощном ноутбуке делать собрался?
>>196977 Начинающие ютуберы и не на такой немощи учились монитровать видео в Premiere.
>>196978 Монтировать видео для ютуба сейчас, и уже давно вообще-то, тоже можно на телефоне.
>>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чан затащить не получится, в отличие от прилагаемого.
