На конференции QoMEX (Quality of Multimedia Experience) в одном из докладов представлены результаты тестирования формата кодирования видео AV2, развиваемого альянсом Open Media (AOMedia) и идущего на смену формату AV1. При использовании метрик оценки качества VMAF (Video Multi-Method Assessment Fusion), разработанных компанией Netflix, использование кодека AV2 позволило добиться снижения битрейта на 32.59% по сравнению с кодеком AV1 при аналогичном уровне качества. При использовании метрик PSRN-YUV (Peak-Signal-to-Noise Ratio 14:1:1) битрейт удалось снизить на 28.63%. При тестировании задействован выпуск AVM 11.0 с эталонной реализацией AV2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64033
Круто, но во сколько десятков раз кодирование у него медленнее, чем у AV1?
Есть еще одна проблема. Когда рипуешь видео, допустим длинное, в 1-2 часа - могут появиться внезапные битые кадры (артефакты). Появиться они могут совершенно рандомно в любом месте. И до сих пор нет ни единого механизма (по крайне мере в Linux мне о таком неизвестно), который бы позволил гарантировать отсутствие битых кадров (рассыпание в квадратики) или хотя бы позволял протестировать/проверить видео на наличие таких битых кадров программным способом, а не сидеть и не пересматривать вручную рипованый видос, стараясь не моргнуть и не пропустить ни один кадр.
Нет таких проблем, исправляйте свой дистрибутив.
Я риповкой видео занимаюсь уже 15 лет. За это время сменил 7-8 компов на разных процессорах (Intel/AMD), с разными типами памяти, разными дистрибутивами. Если не занимаешься ежедневной риповкой видео, то не говори того, в чем не разбираешься. Зайди на любой трекер, скачай 1000 видосов и убедись, что в каждом 5м будут битые кадры. Проблема существует и она пока никак не решается. От новизны железа и дистрибутивов не зависит. Полный рандом.
я думал это пираты косячат, а оно воно как
Хинто: поток можно такой сделать, чтобы "фирменный" плеер нормально играл, а васяновские рип-энкодеры спотыкались и давали артефакт в зависимости от фазы Луны.
Круто, жаль в реальности не так и виной кривые плееры а не видео.
Т.е. ты не отрицаешь наличие васяновских продуктов, которые не знают тонкости потоков...
Примерно 100% рипов сделаны криволапыми и ленивыми идиотами, я в этом давно убедился. Даже цвета запорят, и в место чёрного цвета смотри на серый (не говоря уж об оттенках). Но версия с неисправной памятью мне нравится. Я лично никогда не сталкивался со "случайными" артефактами, только с понятными и воспроизводимыми.
Абсолютная правда. И кривые проприетарные пиписьки вместо плееров ещё не забываем.
Абсолютная неправда. Я тоже лет 10 как создаю рипы для одного известного трекера. Точно знаю, что битые кадры не зависят от оперативки. Можно хоть 100 раз менять оперативку - Memtest будет показывать отсутствие проблем, а во время рипов (использую ffmpeg) будут появляться случайные битые кадры. Этот процесс особо не зависит от настроек рипования. Да и появляться битые кадры будут на любых плеерах, вне зависимости от открытых исходников.
memtest86 - довольно слабый тест, он выявляет проблемы, когда память совсем не держит. Для полной проверки надо гонять разными тестами, включая testmem5 с пресетом extreme, memtest который под винду (причем, на всех ядрах) и y-cruncher. И гонять дня по 2-3 каждый тест.Сучайных ошибок действительно не бывает, чините железо.
Проще prime95, но да.
На моём опыте prime95 хорош для проверки стабильности CPU, хотя OCCT всё-таки чуть лучше. Для проверки именно памяти он не особо хорош по сравнению с теми, что я перечислил. Хотя для уверенности погонять его тоже не помешает, конечно.
ты как оверклокер можешь сказать - у этой вк можно ли разблокировать ядра?
https://i.ibb.co/fdSx7mt9/350.gif
Это уже всё.
Ну то есть ты хочешь сказать, что ~50 планок памяти от 4х разных топовых компаний, которые я сменил на протяжении 10 лет - все негодные, хотя Memtest показывал, что годные? Кучу жестких дисков и остального железа за это время тоже сменил. Так что твои предположения звучат как теория заговора. Ты всегда такими теорими руководствуешься в своей жизни?
У меня для тебя плохие новости, но память без ошибок ты практически не найдёшь, она кончилась примерно лет 15 назад. Сейчас ECC внедряют больше (на каждую плашку), какую-то часть ошибок можно пережить, но ситуация всё хуже. Если раньше это был однозначно брак, то сегодня вариант нормы. Ну, не повезло, попробуй купить из другой партии.
Где ты видел ЕСС в домашних материнках?
В эльбрусах разве нет штатно?
Я это говорю исходя из личного опыта и опыта других оверклокеров. А дальше дело ваше.
Чтобы тестировать на корректность цифровую информацию ее надо дублировать, либо сравнивать с аналоговым эталоном. Нельзя тестить запись в ячейку бита и хранить эталон бита в этой же памяти (в другой ячейке) по определению. Курам на смех ваш мемтест.
Какова вероятность, что флипнутый бит будет один и тот же всегда и повсюду? Вряд ли. Но то что неделю мемтест надо гонять (и не под вендой ясное дело), это тема не здоровая. Остаётся полагаться необъяснимые и не воспроизводимые проблемы при работе с данными (благо, чексуммы сейчас много где), это почти всегда сбой памяти.
> Какова вероятность, что флипнутый бит будет один и тот же всегда и повсюду?я же сказал, сравнивать надо с аналоговым эталоном, буквально в ручную проверять записанные от руки на листе бумаги биты информации. Проблема цифровой информации в том, что записать можно 1, а прочесть 0.
Сравнивается не один бит. Тебе подсказать количество комбинаций? Это сразу будет видно.
хранишь ведь один бит, информация у тебя в двоичном представлении. В этом то и проблема, думаешь легко верифицировать корректность 64 битного сумматора? это надо на вход подать все 2^64 комбинации.
добавочка, либо кодировать одит бит избыточно (несколькими битами) и тогда точно выявится любой флип бита.пс: 55535 - флипнулась одна 5-ка :)
код рида-соломона вообще магия
> код рида-соломона вообще магияобычное избыточное кодирование информации, которая всего лишь снижает вероятность некорректного чтения, чем больше битов используем для кодирования одного бита, тем меньше вероятность некорректно прочесть закодированное.
Полное восстановление произвольного утраченного фрагмента на весь объём парити выглядит интересно. В случае нескольких утраченных фрагментов конечно уже не так замечательно, но тоже работает.
ttps://opennet.ru/63088-occt
https://opennet.ru/63088-occt
memtest86+, это самый удачный тест на сегодня.
Поддерживаю: гонять действительно нужно в течении нескольких суток (около 1000 итераций) (опыт получен после настройки четырех, не сертифицированных производителем материнки, плашек памяти на am4 платформе)
> memtest86 - довольно слабый тест, он выявляет проблемы, когда память совсем не держит.Скажите, какой физический эффект лежит в основе того, что
> И гонять дня по 2-3 каждый тест.? В самом деле, если некоторый конденсатор, хранящий такой-то DRAM-бит, не дежит заряд, то зачем надо 2-3 дня чтобы это выяснить?
> то зачем надо 2-3 дня чтобы это выяснить?чтобы хорошо прогреть, потом остудить и заново завести :)
ECC-память. Работает на процессорах AMD Ryzen (не со всеми платами, но от ASUS работают все, включая среднебюджетные) и последних поколениях Intel (но нужна плата на лучшем чипсете).
> а во время рипов (использую ffmpeg) будут появляться случайные битые кадрыПровода на золотые замени /s
Случайные артефакты при перекодировании цифры это либо в край дохлая память, либо аудиофильские мифы
цвета запарывает твой IPS монитор. я когда смотрю фильмы на ЭЛТ-телеке цвета норм, особенно неоновые вообще супер - любой ЖК отстой.
Элт мониторы, кстати, ещё в 90х позволяли 12 битные цвета отображать (ну, в проф оборудовании можно было встретить). Крайние модели элт вообще шикарные были. Там разве что чёрный не совсем чёрный, как у нынешних OLED, но цветность только недавно подобралась к уровням элт. Всё больше 6-битный цвет с дизеренгом до 8 бит был, но помимо цветов у жк есть проблемы побольше.
Лол. У меня вот QD-OLED, но что-то это не мешает скуфам-риперам ставить limited RGB диапазон (16-235).
Не слушайте опеннетчиков, когда они говорят про видео.Вот выше анон уверен, что добавление 36 значений вместо тысячи (+0.2 бита вместо перехода на 10 бит) решит проблему, а не нарушит общепринятый стандарт и совместимость с плеерами.
В стандарте на HDR (BT.2100) написано:
The narrow range representation is in widespread use and is considered the default. The full range representation is newly introduced in this Recommendation and should not be used for programme exchange unless all parties agree.Но анон выше по-пионерски доит коня.
Нет, тут скорее всего проблема в full RGB / limited RGB. TV и блюреи имеют диапазон яркости 16 - 235 (limited RGB), и наверняка при перекодировании неправильным преобразованием цвета изображение можно запороть.
с чего это ты вдруг решил, что производительтвоего ЖК монитора не нахалтурил? С помощью этого дешевого свистка ты сможешь подключить любой самый современный комп к ЭЛТ-монитору и сравнить одновременно картинку на ЖК и ЭЛТ: https://bgd.by/7aa8fz
но для сравнения в фильмах элт-телек будет лучше мона
> Примерно 100% рипов сделаны криволапыми и ленивыми идиотамиЗнаю лично несколько профессиональных рипперов еще со времен торрентс.ру (познакомились на торрентовках). Ребята, которые этим делом начали заниматься с 2005 года или где-то так, и занимаются до сих пор. У людей за это время накопилась тонна опыта (тысячи рипов), сменилось по 5-10 поколений ПК, различные операционные системы (кто-то начинал на Windows, потом перешел на Linux) и инструменты для создания рипов (кто-то начинал с проприетарных риповалок, потом перешел на опенсорсные). Но одно остается неизменным - даже сегодня никто из них не может быть уверен в том, что получит 100% чистый рип без рандомных артефактов в кадрах. Какие настройки не применялись бы, с какой скорость и алгоритмом ты ни риповал бы. Если даже в веб-рипах на платных площадках иногда встречается такое, о чем тут можно говорить. Нужна технология, которая будет такие вещи если не исправлять на стадии рипования, то хотя бы действительно проверять уже в получившемся видеофайле.
Наверно, это те самые ребята, что x264 кодируют в битрейт поменьше, а то, что психовизуальщина у них плывёт, так это "совершенно необъяснимо". Артефакты не рандомные, они зависят от уровня продакшена и количества добавленных при мастеринге косяков. Что нельзя предсказать, так это как кодек отреагирует на изменение сложности сцены в таком случае. Большинство, типа libaom просто насыпет артефактов, svt-av1 постарается забить всё битрейтом, современные кодеки вроде vvenc попробуют отфильтровать аномалии. Но попытка ограничить битрейт в любом случае всегда приведёт к рассыпанию потока (привет рипперам с 20 летним стажем).
Слушай, ну бред же. Сам на рутрекере сижу года с 2008. Краткий ответ на твой вопрос: нет, это не "те самые ребята".
Напомню про космические лучи, или просто уровень ионизирующего излучения. Чем тоньше техпроцесс тем вероятность "пробоя" выше.
Тут поможет разве что ECC-память. Современные настольные процессоры (с некоторыми оговорками) её поддерживают.
Читаю тред с недоумением. Сколько качаю кино с торрентов - ни разу не видел каких-то артефактов. Я их встречал только на кривых/недокачанных роликах не буду говорить какого содержания.
Купи нормальный монитор вместо вумного телика.
Может, в VLC смотрят. Его квадраты мемом стали.
>познакомились на торрентовкахОтвратительный opsec. Там половина пришедших, наверное, сексотами были.
Да нормальные люди там. Сам пару раз на торрентовках в Питере был (где-то 2010-2014 годы). Посидели в недорогом ресторанчике, пообщались на разные темы, вкусно покушали. На свежем воздухе торрентовка еще лучше была.
>Даже цвета запорят, и в место чёрного цвета смотри на серыйБггг. Да не. Дело не в этом. Просто попробуй сменить свой бюджетный LCD на OLED/AMOLED.
Да нет, именно в этом. В некоторых случаях можно перекодировать протагировав правильный колорспейс, но в большинстве случаев иди за ремуксом (я не встречал запоротых ремуксов).
Играю в VR на Meta Quest 3 и PCVR уже года два, кодек двухпроходной десятибитный AV1. Нет таких проблем, фиксите свой васянодистрибутив ещё раз.
Какой программой для изготовления рипов вы пользуетесь?
Память ЕСС?
Это из-за артефактов кмк. Битрейт ему нельзя ограничивать, но тогда неадекватные скачки будут благодаря чему-то невидимому. Рекомендую всё же не страдать хернёй и взять vvenc от fraunhofer -- он неадекватные аномалии фильтрует и соотношение битрейт/качество в среднем лучше.
Ммммаксимум васянство. Поэтому качать с рутрекера что-то можно только из аниме подраздела, лол.
Да? А откуда качать? С кинопоиска? Прямо в максе смотреть? Неужто дырявый битрейт нетфликса с амазоном (качать, бггг)? Я качаю с рутрекера много лет и fhd и 4к и всё всегда норм, если релизер проверенный.
Тут речь о перекодировании видеопотока в реальном времени, или видел с каких-то носителей? Во втором случае появление битых кадров - это точно не норма.
Зайди на рутрекер или пайратбей, там треть фильмов будет с артефактами - хотя бы в каком-то одном месте за весь фильм да встречаются такие моменты. И это действительно выглядит как странная и хаотичная проблема, которую многие игнорируют.
> странная и хаотичная проблемаЭто для тебя странная, а для кого надо - маркер контента.
В начале 2000-х столкнулся с 25 кадром в одной из пиратских серий аниме Serial Experiments Lain, который был предупреждением от ФБР с их логотипом о, как я понял, не допустимости нелегального видеоконтента и карах за это. Сериал скачал с университетской локалки, который туда попал с пиратских дисков.
А, интересно. На remux-ах мной пока замечено не было. Рипы редко качаю.
В ремуксах проще. Это обычный блюрей, из которого выкинули ремламные ролики и бонусные материалы (всякие допы), чтобы уменьшить размер раздачи. С видеопотоком никаких манипуляций не делается, поэтому ты смотришь стандартный блюрей в его "заводском" качестве. Уж не знаю, как проверяют кадры при создании DVD и Bluray, но пока артефактов на лицензионных дисках не встречал.
Да что ты несёшь-то, чувак? Может, это у тебя железо кривое или плеер?
У меня вот 2 ноутбука и 3 стационарника, но могу подтвердить на своем опыте, что рипы частенько попадаются с "квадратиками" в фильмах с того же рутрекера. Качаю примерно 60-70 фильмов в год (самых разных жанров, в основном качества 1080p), из них десяток стабильно с "квадратиками". Причем независимо от релизера такая фигня.
Так это не артефакты, это просто следствие пониженного качества. Если ты про пикселизацию полутонов и прочие подобные штуки.
Что ты несешь? Смотрю фильмы в стандартном 1080p при среднем битрейте в 12-14к. Ниже даже не качаю. Какая пикселизация? Некоторые кадры в рипах просто разваливаются на квадратики, вот и все. Это происходит во время риппинга. Процесс неконтролируемый и случайный. От битрейта это точно не зависит, потому что это даже на фильмах с битрейтов в 15-20к бывает.
Развала на квадратики не видел. Смотришь не через VLC, случайно? Это у него "фича" такая XD
Я смотрю через MPV, и этот плеер показывает "как есть", да и в голой консоли те же глюки рипов всегда видны.
>там треть фильмов будет с артефактамиДа уберите уже свой VLC подальше от детей. Вместе с тем, на чём вы его запускаете.
вот смотрел как и каждый наверно сотки фильмов и сериалов и ни разу такого не видел. смотрю не на компе конечно. к телеку подключена raspeberry pi4 (до этого была версия помладше и еще был odroid c2) и везде был установлен libreelec (давно на первой малинке был еще openelec)
Такая же фигня. У чувака, походу, какой-то кетайский дивидюшник))
У меня тоже был телик на сасунга. Попробуй как-нибудь начать смотреть скачанные рипы без телика со встроенными улучшайзерами (которые довольно легко фиксят на лету единичные битые кадры) - на обычном плеере без улучшайзеров и на обычном мониторе. Откроешь для себя много нового. Ну или можешь дальше включать клоуна.
Подожжи. Обычный монитор подключен к обычному Коре 2 Дуо?
Ага, смотреть на телике с кучей встроенных улучшайзеров, или на обычном мониторе, лол.
Битые кадры появляются в результате потери ключевого кадра. Может быть решено софтварной перекодировкой. Это когда просто перегоняешь видос ffmpegом без всякого перекодирования. Смысл там примерно в том, что при этом в качестве ключевого кадра будет использовано предыдущее изображение. Конечно гарантия не 100%, но все же лучше, чем просто битое изображение.
И кстати хочу добавить, что на всяких "торрентах" такое возникает именно из за потери кадров камерой, на которую снимали видос. Вы хоть раз пытались снять видос каким-нибудь VLC при помощи вэбки на ноуте? Там кривые тайм-коды выдаются именно из за тормозов самой камеры, а не кривизны проги или вообще какой-то мифической кривизны дистра. Опять же. Все это правится софтварным перекодированием видео.
Подожжи. Они снимали эти свои Звёздные Войны и камера у них там кадры теряла? Через VLC?
> Это когда просто перегоняешь видос ffmpegом без всякого перекодированияСам хоть понял, что за чушь ты написал?
Комментарий от суперпрофи риппинга видео, который ничего не смыслит в матчасти? Говорят же, что в видео, снятом на камеру, могут быть такие вещи, как попутанные тайм-коды. При хардварном рендеренге это не правится. У меня например при записи с вэбки вообще часто нет первого ключевого кадра, так что проги типа Windows Media Player первые секунд 10 видео тупо показывают черный экран. При софтварной перекодировке эта проблема устраняется. Я хз, как объяснить. При этом формируется изображение в софтварном буффере, с которого выполняется новое формирование ключевых и дельта кадров. Глюки при этом с большой долей вероятности исчезают.
А еще из за попутанных тайм кодов в начале видео может показываться не с той скоростью. Например ускоренным. И тупая прогонка через ffmpeg все исправляет. Он вам даже все ошибки в консоли выводит.
ffmpeg -y -i видео.mp4 -vcodec rawvideo -f matroska /dev/nullЕсли будут ошибки декодирования - видео битое.
> который бы позволил гарантировать отсутствие битыхECC (полноценный, не тот что встроен в любой DDR5), фс с чексуммами (btrfs), и даже без этого все обходятся без проблем.
Это цифра, а не аналог, FFS, даже результат действия космических лучей возможно обнаружить и обработать, если у вас откуда-то бьются кадры - то только от кривых рук
Сколько пользуюсь usenet - ни разу не видел битых кадров
Ух ты, интересная инфа. Значит, если собирать домашний рип-центр, то лучше на основе дистра с ZFS или BTRFS? А чем плоха оперативка с поддержкой ECC? Или ничем не плоха, просто недостаточно только лишь одной оперативки? Кстати, FFmpeg поддерживает сегодня ECC? Потому что раньше точно не поддерживал.
> то лучше на основе дистра с ZFS или BTRFSЗачем дистр, просто данные которые не должны портиться хранить на разделе который повреждения способен отслеживать
> А чем плоха оперативка с поддержкой ECC?
У DDR5 есть как-бы встроенный ECC... Однако это не такой же ECC как был в DDR4, для такого же нужна уже DDR5 ECC память. Короче всех запутали.
> Или ничем не плоха, просто недостаточно только лишь одной оперативки?
Без понятия где у этого персонажа портятся данные, но тут как бы только 2 варианта - в оперативке и на диске
Оперативку защищает ECC, диск защищают чексуммы
> Кстати, FFmpeg поддерживает сегодня ECC? Потому что раньше точно не поддерживал.
Для FFMPEG ECC прозрачен, ему не нужно его в явном виде поддерживать.
>Когда рипуешь видео, допустим длинное, в 1-2 часа - могут появиться внезапные битые кадры (артефакты). Появиться они могут совершенно рандомно в любом месте. И до сих пор нет ни единого механизма (по крайне мере в Linux мне о таком неизвестно), который бы позволил гарантировать отсутствие битых кадров (рассыпание в квадратики) или хотя бы позволял протестировать/проверить видео на наличие таких битых кадров программным способом, а не сидеть и не пересматривать вручную рипованый видосЯ не понимаю, в чём у вас проблема. Если битые кадры возникают случайно, то просто прогоните записть несколько раз, а потом покадрово сравните. Вплоть до вычисления разницы между кадрами, и если она выше определённого порога - брак.
>стараясь не моргнуть и не пропустить ни один кадр.Хорошая тема, для машинного обучения.
На кодирование пофиг, если на GPU распараллелят - более жрущее, чем ИИ, сейчас найти трудно, а большую языковую модель, оказывается, за 450 баксов теперь обучить можно на облачном инстансе. Главное чтобы декодирование не тормозило и память не жрало.
Причём не простую, а рефлексивную (рассуждающую в скратчпаде), и на уровне GPT-3 по числу параметров.
А разве не чем выше битрейт, тем лучше?
Нет, чем выше битрейт тем больше нужна полоса пропускания и больше трафик.
Он имеет ввиду качество звука. При прочих равных, качество звука при высоких битрейтах должны быть выше.
Мы же не говорим о битрейте для потока без кодирования. Речь об эффективности кодирования, при котором достигается одинаковый уровень качества, но в одном случае битрейт (объём передаваемых данных) больше, а в другом меньше.
Я про качество звука. Я б еще понял новость, мол, "уменьшили размер выходного файла, сохранив высокий битрейт". Короче, я не сразу понял суть сабжа. Либо заголовок так подали.
> Я б еще понял новость, мол, "уменьшили размер выходного файла, сохранив высокий битрейт".А я бы не понял.
Конечно лучше, но новые кодеки используют не так, оставляют мыльное константное качество и у меньшают битрейт. Вместо того чтобы оставлять битрейт и улучшать качество.
Так что какой бы кодек эффективный не изобрели, мыло на Ютубе будет одинаковое, только меньше по трафику.
Кодеки работают так - как настроили их использующие . К ним свои претензии адресуйте .
а смысл от повышения битрейта если даже текущий в поток не лезет? как никрути а никакой оптики и старлинков на всех не хватает чтобы тиктоки смотреть. а предзагружать пол дня серик с нетфликса на половину памяти телефона тож чёт никто не хочет.
Верно, это одна из причин, размер битрейта уменьшить, по этому улучшают алгоритмы сжатия, что приводит к замедлению кодирования и декодирования, что пытаются нивелировать мощностью процессора или видеокарты смотря на чём кодируют, декодируют. Иначе можно было не заморачиваться с разработкой новых кодеков для понижения битрейта, только переделывать то, что есть под новые процессорные инструкции и использовать например для видео 4К, кодек MPEG-2 видео с 50 кадрами, с битрейтом 50-60Мби/с или выше битрейт.
Как бы не 500-600, это во-первых; во-вторых, тупым увеличением битрейта ограничения кодека не обойти (кто жал в xvid, знает).
> использование кодека AV2 позволило добиться снижения битрейта на 32.59% по сравнению с кодеком AV1 при аналогичном уровне качества
> при аналогичном уровне качестваУчимся читать.
Только в рамках одного кодека.
Раз товарищ админ не хочет возвращать мой коммент, придется повторить.Такими темпами все проприетарные кодеки придется скоро zakopat за ненадобностью.
А ещё виндекапец наступит! *подпрыгивает, высунув язык от возбуждения
Ещё AV1 не внедрили, а уже AV2 придумали... Технологии устаревают до их использования.
AV1 вполне себе внедрили, просто технику нужно менять чаще, чем раз в 20 лет и перестать качать рипы с торрентов, пережатые в AVC за каким-то лядомв любом ГПУ на рынке сейчас есть аппаратная кодировка и декодировка AV1, ютуб и нетфликс стримят видео в AV1, инструменты для скринкаста по возможности кодируют с AV1 для сохранения трафика и места на диске
> в любом ГПУ на рынке сейчас есть аппаратная кодировка и декодировка AV1Мне кажется вы лукавите в этом месте. Мало у кого сейчас есть видеокарта с декодированием и тем более кодированием AV1.
50 серия у нвидии, например, почему нет. У AMD вроде как лучше с этим делом.
1% пользователей, большинство сидят на 3060 или вообще 1060
Даже приставки с av1 уже есть типа tok3, кодек на современном железе есть везде. Другое дело что он работает в разрешениях выше 1080p, поэтому его и не замечают.
> большинство сидят на 3060 или вообще 1060Так у 3060 есть аппаратный декодер.
А 1060... это древность из 2016 года.
Ну уж простите что в ней нет поддержки кодека, который только в 2018м создали.
> Мало у кого сейчас есть видеокарта с декодированиемЧитайте внимательно: "в любом ГПУ *на рынке* сейчас".
Это разумеется означает актуальные модели, а не видяха десятилетней давности или еще более древнее.
АМД декодят начиная с RDNA2, энкодят с RDNA3 (2022 год)
NVidia декодят с RTX 3000, энкодят с RTX 4000.
И то, и другое 2020 и 2022 год соответственно.Т.е. любая не60mжацкая видяха за последние 5 лет поддерживает AV1.
В том то и дело что с внедрением AV2 вся эта актуальная на сегодня техника превращается в тыкву при просмотре видосиков.
Вы лаптопы тоже предлагаете менять каждые пару лет?
> В том то и дело что с внедрением AV2 вся эта актуальная на сегодня
> техника превращается в тыкву при просмотре видосиков.А вы уверены что AV2 не использует такие же хардварные блоки что и AV1?
Но даже если не будет поддерживаться - значит тыртуб будет вам отдавать AV1 или что-то более древнее.> Вы лаптопы тоже предлагаете менять каждые пару лет?
Не пару лет. AV1 релизнули 7 лет назад, хардварную поддержку он получил через два года.
Если с AV2 будет аналогично... то, вы что, сидите за ноутами по 7 лет О_о???
>Мало у кого сейчас есть видеокарта с декодированием и тем более кодированием AV1Intel Arc начиная с Arc A310, не говоря про b570/b580:
- https://cdn.3dnews.ru/assets/external/illustrations/2025/01/...
- https://cdn.3dnews.ru/assets/external/illustrations/2025/01/...
- https://cdn.3dnews.ru/assets/external/illustrations/2025/01/...
декодирование уже повсюду есть. и даже в софтовом исполнении отлично работает, а кодирование нужно то полуторе стримеров по сути.
>просто технику нужно менять чаще, чем раз в 20 лет и перестать качать рипы с торрентовХороший, годный, законопослушный потребитель. Иди уже обратно в своё стойло.
Я, конечно, понимаю нестерпевание за торренты, но объективно — рипы там рассчитаны на «массы». Которые ещё несколько лет назад жаловались, что «DVD-плеер не играет!». Да и до сих пор раздачи в Xvid как бы не популярнее, чем в AVC.
> Ещё AV1 не внедрилиЧто значит не внедрили? Каждое второе видео из новых на ютубе - AV1.
Другое дело, что им приходится поддерживать всякое легаси... но это не значит "не внедрили"
Пять лет назад, в Tiger Lake появилось декодирование AV1:
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Develop...
А зачем мне tiger lake, если 3750 + gtx 1070 все еще тянет в 1080p все интересные мне игры?
Так речь про AV1, что его спокойно декодирует интеловская встройка.
Таким образом лаптоп 6-летней давности будет считатья устаревшим, а 5-ти ещё актуальным. Это по-вашему нормально?
Никто же в одночасье не отрубит поддержку устаревшего кодека. Тот же YouTube никак в этом не заинтересован.
Постепенный переход.
А как тогда применять какие-то новые технологии ?
Статистика ведь ведётся по реальному использованию : средний срок службы ноута 3-5 лет , пк 3-8 лет . Принятый производителями ритм обновления - 4 года . И никто не будет подстраиваться под любителей кататься на "жестянке Лиззи" .
Да, это нормально.
Вы поди 90-е не помните — тогда компьютерная техника через год считалась устаревшей.
Отлично. Ждём в AVIF. JPEG и PNG должны умереть.
Для начала бы HEIF на AVIF заменить в камерах...
в камерах хейф предпочтительней пока он с прицелом на них и делался в отличии от авиф который огрызок для вэба.
> Отлично. Ждём в AVIF. JPEG и PNG должны умереть.Самое забавное, что некоторые инвалиды в это действительно верят. Даже его лосслесс ни разу не лосслесс, я так и не смог добиться без потерь (webp умеет). Ни один формат сжатия на основе видеокодека не способен заменить даже никчёмный доисторический jpeg. И jpegxl -- буквально первая жизнеспособная ему альтернатива. Ну а пнг это пнг, в среднем это безопасный вариант, с рядом оговорок. Не сказал бы что целиком лосслесс по ряду причин, но тут больше претензия к софту -- tiff тоже бывает разный, да даже с targa есть оговорки. Да и медленный неоправданно. В jpegxl постарались все сложности решить адекватными спецификациями и стандартизацией, но где-то мы это уже видели.
Ну в форматах для веба lossless явно не приоритет. Там важно в приемлемое качество уместить в минимальный размер. AVIF весит меньше WEBP, при этом качество выдает сильно лучше. Особенно это заметно на градиентах, которые webp шакалит как последний шакал. Jpeg весит сильно больше, а шакалит в других местах. Я бы сказал, что для веба - AVIF сейчас топ. В чем там lossless хранить уже другое дело.
К слову, если для веба генерить avif через imagick, то это дно. Ffmpeg выдает результат сильно лучше.
Png и jpeg конечно же долго не умрут (сначала gif надо похоронить).
Не, ну я avif использую из-за размера, но не в восторге. Он очень сильно запарывает цвета и мылит, webp с sharp-yuv=1 почти не отличить от jpeg. Разницы между imagemagic и libheif не заметил, оба косячные. Чтобы webp картинку не порол, по-моему, надо выставлять всякие image-hint=picture дополнительно -- сам он постоянно не ту эвристику выбирает. В webp с vp9 уже лучше с градиентами, но это всё ещё видеокодек. Jpegxl просто красота, но если ориентироваться на размер jpeq q93 (или lossless).
Да любой из нас раньше помрёт, чем PNG помрёт.
Меня больше волнует хардварная поддержка этого кодека в видушках. Нет поддержки - привет жер CPU и GPU. h264 хотя бы поддерживается даже утюгами. Если конечно дрова есть. А то видушка 10-летней давности, а в линух все никак поддержку h264 не завезут. В винде работает.
Лет эдак через 5 будет, контент и того позже.
А x264 для кого?
Вот протестируйте на этом примере сколько будет жрать ресурсов.
Выставляйте вручную качество от 1080 до 8k:
https://www.youtube.com/watch?v=b3ootXSAaqE
30% это существенное улучшение, молодцы!Ждём svt-av2 и сравнений с кодеками VVC.
Для ютуба - улучшение, а рядовому пользователя всёравно качается ли видео со скоростью 3 или 2мб/с.
У рядового пользователя небесплатный мобильный трафик бывает.
> небесплатный мобильный трафикНадеюсь, ты получаешь достаточную зарплату, чтобы в состоянии оплатить 500..1000 руб/мес за безлим видео на мобилке?
А безлим VPN туда входит?
напишу здесь, так невозможно коментить скрытые модератором сообщения == вот тут народ пишет что я не вижу битых кадров из-за улучшайзеров на телеке (к телеку подключена малинка (raspberry pi 4 с libreelec на борту)) -- так вот телек древний (года 2015, а может и раньше) не смарт и даже плеера в нем никакого нет. тупой и простой телек
Так битые кадры как раз получаются процессом улучшайзингда.
Ага, это с каких пор улучшайзинги появились в MPV?
> невозможно коментить скрытые модератором сообщенияВозможно.
1. Оно тоже мылит, съедая детали как гугловые кодеки?
2. Медкадровое сжатие — это хорошо, но как оно дружит с ... аниме? Типовой случай когда сцена более-менее статична, просто камера проходит по ней в сторону всё ещё воспринимается как серия кадров с изменениями во всех блоках?
1. Скорее всего радикального изменения тут не будет. Но и для av1 есть (точнее, был) svt-av1-psy, где вопрос мыла в целом решён.
2. Если завезли большие блоки, то должно хорошо сжиматься.
> как оно дружит с ... аниме?никак не дружит
> AVM 11.0Что это такое?
Это libaom?
https://gitlab.com/AOMediaCodec/avm
"AVM (AOM Video Model) is the reference software for next codec from Alliance for Open Media (https://aomedia.org/)""AV2 — это сам видеокодек (спецификация формата и алгоритмов), а AVM (AOM Video Model) — эталонная реализация/референс‑софт, который демонстрирует и проверяет эту спецификацию. AV2 задаёт правила битстрима и поведение декодера; AVM показывает, как эти правила реализуются на практике (кодировщик/декодер, тесты, измерения)"
"AV2 — спецификация (формат битстрима и алгоритмы). Это набор правил и описаний, не исполняемый код.
AVM — референсная реализация этой спецификации (энкодер/декодер в виде кода). AVM показывает, как должна работать AV2 и служит эталоном для тестов и совместимости.
Как с libaom-av1: сейчас libaom — готовая реализация AV1, включаемая в FFmpeg. Аналогично в будущем AVM (реализация AV2) может быть интегрирована в FFmpeg как реализующий AV2 кодек.
Процесс: спецификация AV2 разрабатывают/утверждают; затем её реализуют в коде (AVM и/или другие реализации); интеграция в проекты (FFmpeg) происходит после появления стабильной реализации/интерфейсов"Вроде всё логично правильно.
