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