Comments 194
Старая фраза, «чтобы фильмы смотреть можно было» обретает новую жизнь.
/хмыкая
Доводилось в конце 1990х держать в руках железный ускоритель для просмотра видео, который цеплялся к разъему на видяшке и таки да, реально ускорял просмотр видео.
История идет по спирали, бгг.
Доводилось в конце 1990х держать в руках железный ускоритель для просмотра видео, который цеплялся к разъему на видяшке и таки да, реально ускорял просмотр видео.
История идет по спирали, бгг.
Voodoo2 от 3dfx же ) У меня была такая.
Voodoo 3 уже самостоятельный девайс
Voodoo 3 уже самостоятельный девайс
Ненене.
Это было еще до пришествия вуды, и встретилось мне только один раз. Как называлось и чье было — за давностию лет не помню совсем.
Маленькая такая платка с большим чипом, которая втыкалась в штырьковый разъем на самой видеокарте, внутри, и использовалась не для игрушек а именно для видео. Видео которое на том компе едва шевелилось с этой платкой бодро игралось во весь экран.
Это было еще до пришествия вуды, и встретилось мне только один раз. Как называлось и чье было — за давностию лет не помню совсем.
Маленькая такая платка с большим чипом, которая втыкалась в штырьковый разъем на самой видеокарте, внутри, и использовалась не для игрушек а именно для видео. Видео которое на том компе едва шевелилось с этой платкой бодро игралось во весь экран.
Что-нибудь такое, наверное.
MPEG декодер. Сам такие вживую не видел, только в западной прессе о них читал.
Маленькая такая платка с большим чипом, которая втыкалась в штырьковый разъем на самой видеокарте, внутри, и использовалась не для игрушек а именно для видео.
У меня была такая, но отнюдь не маленькая, а размером с тот же Voodoo, зато была совместима со всеми видеокартами, а не только с какой-то одной конкретной. Называлась Creative Encore Dxr3.
Ну да, мой 6-летний Core i7 уже едва справляется с 4k 60 fps, а на AV1 совсем захлёбывается, сплошное дёрг-дёрг, а тут ещё хлеще кодек подвезли.
Сдаётся мне дело не в процессоре. Мой 6 летний core i7 вполне справляется и с 8к.
Дело скорее всего в видеокарте, у меня i5-2400 и gtx1060 3gb — легко запускаю 8к 60фпс на ютубе.
Всё верно — дело в видеокарте. GTX 1060 умеет в аппаратное декодирование HEVC и vp9, в результате трудится она, а процессор отдыхает.
у меня такая же система: i5-2400, 1060 6гб, 8к 60 фпс практически не воспроизводит, 4к с подергиваением. проц нагружен на 100% видюха только на 10%. как заставить видеокарту брать задачу на себя?
Какой браузер? Или плеер?
браузеры: firefox, vivaldi, opera. в системе плеер от медиа плеер классик.
В Firefox достаточно включить аппаратное ускорение в настройках. Попробуйте в Edge, там это ускорение выключить достаточно сложно.
попробовал аппаратку в огнелисе, выбрал в настройках Максимальное число процессов контента — 7, перезагрузил браузер и разницы не заметил, кроме возросшего потребления памяти до 8гб, в моей системе 16 гб.
смотрю этот ролик www.youtube.com/watch?v=ZkofUXbwGDs
если включаю 1440, то графический проц видеокарты нагружен на 30%, если 2160, то гп нагружен на 20-25 циклично уходя в ноль. ну а в 8к вообще спит. проблему с интернетом или с буферизацией не вижу, достаточно быстро грузит ютуб.
смотрю этот ролик www.youtube.com/watch?v=ZkofUXbwGDs
если включаю 1440, то графический проц видеокарты нагружен на 30%, если 2160, то гп нагружен на 20-25 циклично уходя в ноль. ну а в 8к вообще спит. проблему с интернетом или с буферизацией не вижу, достаточно быстро грузит ютуб.
В Edge попробовали?
еще нет, но сейчас этим займусь.
эм, у меня операционка винда 7, я так понял edge под нее нет?
эм, у меня операционка винда 7, я так понял edge под нее нет?
Да, edge под нее нет. Тогда не знаю, что вам посоветовать — можете попробовать параллельно поставить 10ку и проверить в ней, в том числе на своих стандартных браузерах. Драйвер поставить с сайта Nvidia не забудьте. На 10ке «в стоке», с драйвером, Firefox и Edge должны работать «из коробки», без каких либо настроек.
Причем тут видеокарта? Аппаратного декодирования AV1 в потребительских видеокартах не будет еще года 3 минимум.
UFO just landed and posted this here
Сомневаюсь, что это даст существенной рост производительности.
Разрешение видео, частота кадров, сложность кодеков растет, а производительность процессоров не особо.
Скорее нужна поддержка декодирования отдельными процессорами (видеокартой)
Смысла использовать универсальный центральный процессор для всех задач нет.
Раньше графика в играх обрабатывалась на CPU, позже пришли к использованию видеокарт.
Там все вычисления уже на GPU, всё изначально векторизировано. Но как вариант для декодирования такого видео вполне можно приспособить habr.com/company/intel/blog/430492 :).
Интересно девки пляшут, однако хотелось бы подтверждений от независимых экспертов, ибо есть сильное подозрение что сеть натаскали на тестовые последовательности, что не разу не гарантирует качество и адекватность предсказаний последовательностей иных…
В скринах бросается в глаза блочность традиционных кодеков, она же плодит ошибку большую чем например у MotionJPEG2000 однако снижение битрэйта всё расставляет по своим местам.
В скринах бросается в глаза блочность традиционных кодеков, она же плодит ошибку большую чем например у MotionJPEG2000 однако снижение битрэйта всё расставляет по своим местам.
Так не поэтому ли скорость кодирования 2 кадра в секунду, что сеть каждый раз обучается?
Исключено. Для высокого разрешения 2 кадра в секунду на H.265/VP9 — довольно быстро. Core i5-4570 кодирует VP9 1920×1080 примерно 2 кадра в секунду.
Тут кодируется 2 кадра в секунду в VGA на Nvidia Tesla V100. Я сильно подозреваю, что, если на тот же VP9 бросить такие же мощности, он сильно выиграет в качестве.
VP9 не кодируется на видеокартах, к сожалению.
Но это не мешает ему все-равно работать в десятки раз раз быстрее даже на обычном процессоре против нейросети работающей на таком вычислительном монстре как Tesla V100.
И в целом мысль wataru очень правильная — если кодеку основанному на традиционных подходах дать сравнимые вычислительные мощности для кодирования — он порвет все эти нейросети как тузик грелку по степени сжатия и/или качества картинки на выходе.
Например те же VP9 и H.265 существенно обходят по качеству и сжатию H.264/AVC практически только за счет того, что им позволено использовать в разы больше вычислений при кодировании. Благо кратно выросшие с момента появления x264 мощности железа позволили это сделать.
Стоит у современных кодеков эти дополнительные вычислительные мощности отобрать — и они сразу сдуются, практически до результатов старых кодеков. А при совсем малых допусных вычислительных возможностях — вообще могут и проиграть старым кодекам по соотношению качество/степень сжатия.
Горизонтальная шкала логарифмическая:
— горизонтальная ось = секунд на кодирование 1 кадра с одним и тем же итоговым качеством
— вертикальная = относительный битрейт чтобы обеспечить одинаковое качество
За точку отсчета взят х264 @ VerySlow пресете кодирования.
И в целом мысль wataru очень правильная — если кодеку основанному на традиционных подходах дать сравнимые вычислительные мощности для кодирования — он порвет все эти нейросети как тузик грелку по степени сжатия и/или качества картинки на выходе.
Например те же VP9 и H.265 существенно обходят по качеству и сжатию H.264/AVC практически только за счет того, что им позволено использовать в разы больше вычислений при кодировании. Благо кратно выросшие с момента появления x264 мощности железа позволили это сделать.
Стоит у современных кодеков эти дополнительные вычислительные мощности отобрать — и они сразу сдуются, практически до результатов старых кодеков. А при совсем малых допусных вычислительных возможностях — вообще могут и проиграть старым кодекам по соотношению качество/степень сжатия.
Горизонтальная шкала логарифмическая:
— горизонтальная ось = секунд на кодирование 1 кадра с одним и тем же итоговым качеством
— вертикальная = относительный битрейт чтобы обеспечить одинаковое качество
За точку отсчета взят х264 @ VerySlow пресете кодирования.
В скринах бросается в глаза блочность традиционных кодеков
Блочность там неспроста. Именно разбиение кадра на блоки малого размера даёт приемлемую вычислительную сложность и относительную гомогенность входного изображения в пределах малого блока. Отсюда хорошее приближение исходного изображения косинусными преобразованиями и методами меж- и внутри- кадрового предсказания.
Сравнение кодеков выглядит необъективным. Н.264/Н.265 построены вокруг В-кадров и заточены под метрику PSNR. Меж тем, В-кадры не использовались, а качество измеряли по метрике SSIM. Если авторам интересна именно эта метрика, то стоило добавить в сравнение кодек AV1. Желаю авторам удачи, но сомневаюсь что статью примут в серьёзный рецензируемый журнал.
Заголовок статьи, конечно, жёлтый. Как минимум, не хватает сравнения с AV1.
Верно, причём современные медиа форматы очень сильно оптимизируются также под быстрое набор инструкций потребительских ПК. Создатели существующих кодеков даже не ставили такой (непрактичной) задачи, которую поставили авторы статьи.
И я думаю, что стоит применить ML для создания кодека оптимизированного под реальный набор инструкций. Только вот эта задача уже настоящая и практическая, и даже просто среднего результата будет очень сложно добиться.
угу. Для начала хотелось бы услышать комментарии от Ясона Гаретта, потому что как правило он дает рекомендации по тому, что бы ultrafast настройки x264 поменять на что-то не столь радикальное
Только добрался. Посмотрели с коллегами.
Классика жанра )))
Для начала — результаты тестирования кодеков 2017 (ПРОШЛОГО) года:
Что можно сказать про авторов:
Секрет успеха 1: выкидываем из сравнения сегодняшнего лидера, выбираем пресеты послабее для хороших кодеков и выбираем заведомо слабую для самого сильного аналога! И, бинго, мы первые!!! )))
А есть еще и параметры, например, «To remove B-frames, we use H.264/5 with the bframes=0 option, VP9 with -auto-alt-ref 0 -lag-in-frames 0, and use the HM encoder lowdelay P main.cfg profile.» То есть они не смогли побить обычные кодеки в честном соревновании и выбрали для статьи что соревнуются только в low-latency режиме. При том что у них декодер работает 2 сек на кадр, то есть ни о каком low-latency даже близко говорить нельзя.
Тонким издевательством на этом фоне выглядят рассуждения о том, что некоторые кодеки могут заглядывать вперед (на минуточку — B-фреймы были стандартизованы еще в 1992 году в MPEG-2).
Кстати — в AV1 вполне себе используются нейросети, но точечно и по делу. Но сказать «второй кодек с машинным обучением» — согласитесь, не прозвучит ), особенно если вы решили первый проигнорировать как сильного конкурента ))))
Секрет успеха 2: Наглость, как известно города берет, а тут задача не менее сложная. Рассуждаем о том, как безнадежно устарели текущие кодеки и отключаем у них параметры, которые обеспечивают им повышение степени сжатия.
Также доставляют картинки «оптического потока» H.265 и у них. У них картинка выглядит более гладкой, значит она (конечно!) более правильная и современная ))). Есть один маленький нюанс. Эту картинку надо СЖИМАТЬ. Т.е. она должна быть компактно представлена. И (внезапно!) выясняется, что компактнее вовсе не означает красивее, тем более если речь идет о технических внутренних данных, которые никто никогда кроме разработчиков не видит! Скорее наоборот — что-то квадратное великолепно сжимается, а что-то плавное — плохо. Т.е. корректно было бы привести рядом во сколько обошлось сохранение векторов движения справа и слева, во сколько обошлась межкадровая разница справа и слева. Ну и кадры, которые получились с их значениями MS-SSIM, обязательно. После этого появляется предмет обсуждения, если там есть о чем говорить, конечно.
Секрет успеха 3: Вырываем из контекста какой-то кусок внутренних данных, который визуально выглядит красивее (как вариант — можно что-то красиво визуализировать). Показываем у нас и у них. И неважно, как оно сжимается. Люди (включая инвесторов))) реально любят красоту!
Вообще кому интересно — вот так примерно кодеки сегодня располагаются в многомерном пространстве реальных требований:
Как видно — картинка реально многомерная и для реального успеха нужно в нескольких измерениях преуспевать.
В качестве вишенки на торт — нет смысла сравнивать кадры. В кодеке (особенно если он пытается выдержать битрейт, он ведь у нас работает в low-latency режиме с ограниченным каналом, не правда ли?) заведомо идут осциляционные процессы. В таких режимах можно на примерах доказать, что MPEG-2 точно превосходит AV1. Главное взять последовательность подлиннее ))) (бонусный секрет)))
Ну и публикуется все на архиве, а не в материалах Data Compression Conference ), ведь на архиве не будут задавать неприятных вопросов до публикации! )))
Всем удачи!
Классика жанра )))
Для начала — результаты тестирования кодеков 2017 (ПРОШЛОГО) года:
Что можно сказать про авторов:
- Для начала — они начисто проигнорировали наличие AV1, который сегодня (молитвами Google) развивается крайне быстро, причем в открытых исходных текстах! И в общем-то всех рвет (но мучительно медленный пока).
- Далее, авторы пишут: «We evaluate H.264 and H.265 in both the default preset of medium, as well as slower.» Как легко заметить на графике выше — есть еще пресеты Slow, Veryslow и Placebo, причем в последнем есть варианты с 2 и 3 проходами. И это позволяет заметно больше десятка процентов наиграть! Просто за счет выбора другого пресета!
- Ну и, наконец, забавно выглядит выбор базовой реализации для H.265. Если посмотреть на график сравнений этого года
хорошо видно, что хорошая коммерческая реализация H.265 (HW265) при высокой скорости работы обгоняет по степени сжатия, сделанные на основе базовой (UC265 и sz265) В ПОЛТОРА РАЗА!!!
Прикол, что при этом у них волшебным образом совпали графики реализаций H.264 и H.265, т.е. кодеки, которые разделяет 13 лет развития типа работают одинаково по эффективности. Но боже, кого это смущает? )))
хорошо видно, что хорошая коммерческая реализация H.265 (HW265) при высокой скорости работы обгоняет по степени сжатия, сделанные на основе базовой (UC265 и sz265) В ПОЛТОРА РАЗА!!! Секрет успеха 1: выкидываем из сравнения сегодняшнего лидера, выбираем пресеты послабее для хороших кодеков и выбираем заведомо слабую для самого сильного аналога! И, бинго, мы первые!!! )))
А есть еще и параметры, например, «To remove B-frames, we use H.264/5 with the bframes=0 option, VP9 with -auto-alt-ref 0 -lag-in-frames 0, and use the HM encoder lowdelay P main.cfg profile.» То есть они не смогли побить обычные кодеки в честном соревновании и выбрали для статьи что соревнуются только в low-latency режиме. При том что у них декодер работает 2 сек на кадр, то есть ни о каком low-latency даже близко говорить нельзя.
Тонким издевательством на этом фоне выглядят рассуждения о том, что некоторые кодеки могут заглядывать вперед (на минуточку — B-фреймы были стандартизованы еще в 1992 году в MPEG-2).
Кстати — в AV1 вполне себе используются нейросети, но точечно и по делу. Но сказать «второй кодек с машинным обучением» — согласитесь, не прозвучит ), особенно если вы решили первый проигнорировать как сильного конкурента ))))
Секрет успеха 2: Наглость, как известно города берет, а тут задача не менее сложная. Рассуждаем о том, как безнадежно устарели текущие кодеки и отключаем у них параметры, которые обеспечивают им повышение степени сжатия.
Также доставляют картинки «оптического потока» H.265 и у них. У них картинка выглядит более гладкой, значит она (конечно!) более правильная и современная ))). Есть один маленький нюанс. Эту картинку надо СЖИМАТЬ. Т.е. она должна быть компактно представлена. И (внезапно!) выясняется, что компактнее вовсе не означает красивее, тем более если речь идет о технических внутренних данных, которые никто никогда кроме разработчиков не видит! Скорее наоборот — что-то квадратное великолепно сжимается, а что-то плавное — плохо. Т.е. корректно было бы привести рядом во сколько обошлось сохранение векторов движения справа и слева, во сколько обошлась межкадровая разница справа и слева. Ну и кадры, которые получились с их значениями MS-SSIM, обязательно. После этого появляется предмет обсуждения, если там есть о чем говорить, конечно.
Секрет успеха 3: Вырываем из контекста какой-то кусок внутренних данных, который визуально выглядит красивее (как вариант — можно что-то красиво визуализировать). Показываем у нас и у них. И неважно, как оно сжимается. Люди (включая инвесторов))) реально любят красоту!
Вообще кому интересно — вот так примерно кодеки сегодня располагаются в многомерном пространстве реальных требований:
Как видно — картинка реально многомерная и для реального успеха нужно в нескольких измерениях преуспевать.
В качестве вишенки на торт — нет смысла сравнивать кадры. В кодеке (особенно если он пытается выдержать битрейт, он ведь у нас работает в low-latency режиме с ограниченным каналом, не правда ли?) заведомо идут осциляционные процессы. В таких режимах можно на примерах доказать, что MPEG-2 точно превосходит AV1. Главное взять последовательность подлиннее ))) (бонусный секрет)))
Ну и публикуется все на архиве, а не в материалах Data Compression Conference ), ведь на архиве не будут задавать неприятных вопросов до публикации! )))
Всем удачи!
Можно вопрос по последней картинке? Каким образом у AV1 стал high encoding performance? Или я что-то не так понял? Он сейчас хоть что-то из кодеков обгоняет по скорости?
Тему статьи точно обгоняет )
Эта картинка из статьи, которую пишут нам из машины времени, года из 2022.
www.streamingmedia.com/Articles/Editorial/Featured-Articles/At-the-Battle-of-the-Codecs-Answers-on-AV1-HEVC-and-VP9-128213.aspx?CategoryID=423
www.streamingmedia.com/Articles/Editorial/Featured-Articles/At-the-Battle-of-the-Codecs-Answers-on-AV1-HEVC-and-VP9-128213.aspx?CategoryID=423
In terms of decode performance, one attendee reported that a major social media company was already distributing AV1 streams to mobile viewers with efficient playback, using decoders included in the company’s iOS and Android apps. I shared my finding that Chrome and Firefox were playing 1080p video on a single-CPU HP ZBook notebook using between 15 and 20 percent of CPU resources.
AV1 streams to mobile viewers with efficient playback, using decoders included in the company’s iOS and Android appsНо ведь в вашей цитате речь идет о декодинге видео, а не энкодинге. Мне кажется, что на картинке что-то кардинально неверно со шкалой «encoding performance», потому что у H264 эта производительность ниже, чем у AV1…
Плюс почему-то свободна low-половина у следующей шкалы, декодинга. Тогда уж AV1 нужно было поставить в low (пока мы еще в 2018), а hevc — по середине, как мне кажется, иначе ерунда какая-то выходит.
На картинке многое не соответствует действительности, не только encoding performance (хотя там имелось в виду complexity). А ниже, в decoding performance, вероятно, речь о производительности, а не сложности.
В Decoder install base VVC находится не в самом левом положении, хотя для него декодер появился, ну, пару месяцев назад, и еще не установлен ни у кого, кроме как у разработчиков этого кодека.
Я привел цитату, потому что она просто нереалистична. В цитате у человека на ноутбуке декодирование FullHD AV1 отнимает 15-20% CPU, в то время как на десктопном четырехядерном i5-4570 мой компьютер с трудом декодирует такой видеопоток чуть быстрее реалтайма (24 fps), не говоря уже о мобильных устройствах.
В Decoder install base VVC находится не в самом левом положении, хотя для него декодер появился, ну, пару месяцев назад, и еще не установлен ни у кого, кроме как у разработчиков этого кодека.
Я привел цитату, потому что она просто нереалистична. В цитате у человека на ноутбуке декодирование FullHD AV1 отнимает 15-20% CPU, в то время как на десктопном четырехядерном i5-4570 мой компьютер с трудом декодирует такой видеопоток чуть быстрее реалтайма (24 fps), не говоря уже о мобильных устройствах.
У слова performance — много значений. Затрудняюсь сказать, что имели ввиду коллеги, скорее перепутано направление первой оси. AV1, как я писал выше — не просто медленный, он мучительно медленный, хотя его и ускоряют сейчас довольно эффективно.
Суммарно там в этом году в 20-100 раз ускорение (очевидно с падением эффективности) и до конца года обещают еще:
Так что чуть позднее можно будет более предметно говорить, что в итоге получилось.
Вообще средний кодек сегодня это минимум 50 квалифицированных человеко-лет, и минимум 4 гора разработки (чаще больше) и если пригнать больше людей, результат можно только ухудшить. Поэтому остается ждать и смотреть, что получается по ходу.
Суммарно там в этом году в 20-100 раз ускорение (очевидно с падением эффективности) и до конца года обещают еще:
Так что чуть позднее можно будет более предметно говорить, что в итоге получилось.
Вообще средний кодек сегодня это минимум 50 квалифицированных человеко-лет, и минимум 4 гора разработки (чаще больше) и если пригнать больше людей, результат можно только ухудшить. Поэтому остается ждать и смотреть, что получается по ходу.
AV1, как я писал выше — не просто медленный, он мучительно медленныйЗнаю, вот и удивился. Хотел его попробовать, но просто не дождался окончания процесса.
Поэтому остается ждать и смотреть, что получается по ходу.Ну я не могу сказать, что куда-то спешу, пока HEVC вполне справляется с задачами, которые я ему ставлю. С VP9 устал воевать с колорспейсами…
> видно, что хорошая коммерческая реализация H.265 (HW265)
Что-то её не видать в интернетах нигде. Не поделитесь советом, где она могла бы водиться? :)
Что-то её не видать в интернетах нигде. Не поделитесь советом, где она могла бы водиться? :)
Вопрос к авторам кодека. Они точно предлагают его на b2b рынке, про b2c не слышал.
Жаль. Получается, для простых смертных его как бы и не существует в природе. И результаты тестирования не повторить.
Давится гора квадровидюшек сутками напролёт в x265 — до 1.4Тб разрослись, никаких дискет не напасёшься!
crf 23 slower ужимает втрое, а так было б вчетверо и порезвее…
С Tencent Shannon Encoder — такая же петрушка, видимо?
Давится гора квадровидюшек сутками напролёт в x265 — до 1.4Тб разрослись, никаких дискет не напасёшься!
crf 23 slower ужимает втрое, а так было б вчетверо и порезвее…
С Tencent Shannon Encoder — такая же петрушка, видимо?
Как минимум в их облаке он будет.
А так в целом рынок отдельных кодеков в упадке, за них мало кто готов платить. Как следствие производители доходят до того, что в инсталлируемом в систему виде кодеки вообще не выпускают. В принципе их можно понять. У вас запрос на бесплатный вариант?
Тенсентовский — тоже будет в их приложении и облаке однозначно.
А так в целом рынок отдельных кодеков в упадке, за них мало кто готов платить. Как следствие производители доходят до того, что в инсталлируемом в систему виде кодеки вообще не выпускают. В принципе их можно понять. У вас запрос на бесплатный вариант?
Тенсентовский — тоже будет в их приложении и облаке однозначно.
В идеале бесплатный, как x265, но и умеренно платный сгодился бы, главное платёж разовый.
А за облака терабайтные платить, давящие в 265 — проще ещё один винчестер поставить.
А за облака терабайтные платить, давящие в 265 — проще ещё один винчестер поставить.
Вы хотите качество как у лучшего платного, а цену как у бесплатного. Желание понятное ), но расклад простой — чтобы продукт выпускать, надо чтобы сходилась экономика процесса, т.е. кто-то должен оплачивать банкет.
Кстати, в вашем случае видео с квадрокоптерами скорее всего даже пресетами можно наиграть процентов 20-30. Посмотрите evt.guru, если интересно — пишите.
Кстати, в вашем случае видео с квадрокоптерами скорее всего даже пресетами можно наиграть процентов 20-30. Посмотрите evt.guru, если интересно — пишите.
Крутая затея!
Ну, в моей ситуации выгоднее купить 3 винчестера по 12Тб, чем платить $1000 за пресет.
А так затея прикольная. Любопытно, как реализовано…
Исходное видео кодируется пользовательским пресетом. Режется на небольшие кусочки по ключевым кадрами. Выбирается несколько наиболее прожорливых, нарезаем их из оригинального видео. Затем методами оптимизации (градиентный спуск?) ищем минимум битрейта, пробуя соседние значения всех изменяемых параметров (штук 30-40, которыми есть смысл играться?), отслеживая время работы, итоговый битрейт и качество (метрика VMAF?).
Привет, кстати, из стримбокса :)
Ну, в моей ситуации выгоднее купить 3 винчестера по 12Тб, чем платить $1000 за пресет.
А так затея прикольная. Любопытно, как реализовано…
Исходное видео кодируется пользовательским пресетом. Режется на небольшие кусочки по ключевым кадрами. Выбирается несколько наиболее прожорливых, нарезаем их из оригинального видео. Затем методами оптимизации (градиентный спуск?) ищем минимум битрейта, пробуя соседние значения всех изменяемых параметров (штук 30-40, которыми есть смысл играться?), отслеживая время работы, итоговый битрейт и качество (метрика VMAF?).
Привет, кстати, из стримбокса :)
Ну, в моей ситуации выгоднее купить 3 винчестера по 12Тб, чем платить $1000 за пресет.Это совершенно понятно, но это и ответ, почему производители хорошие кодеки не портируют, рынок мал, типа — используйте бесплатные. )
Любопытно, как реализовано…Реализовано по-другому. Активно зарабатываем на том, что чтобы на ролике в 600 кадров попробовать все 49 параметров даже вполне быстрого x264 нужно 10 в 13 степени лет, т.е. больше 400000 возрастов земли. И чтобы сделать перебор в 49-мерном пространстве градиентный спуск вам не поможет, оно не дифференцируемо ). Подавляющее большинство компаний эту задачу не тянет, публикаций нет. В общем — вполне)
Привет, кстати, из стримбокса :)
Забавно. Сейчас там?
Это как сравнивать теплое с мягким.
Текущие кодеки изначально исходят не из максимальной компрессии. А из возможной компрессии с учетом ограничений (сложности и цены) декодера (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles). Поэтому в таких кодеках используются ассиметричные алгоритмы, такие что декодирование должно быть достаточно простым, легко параллелизуемым и локальным (что бы можно было создать специализированные чипы). Тогда как кодирование может быть в разы более трудоемким.
Текущие кодеки изначально исходят не из максимальной компрессии. А из возможной компрессии с учетом ограничений (сложности и цены) декодера (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles). Поэтому в таких кодеках используются ассиметричные алгоритмы, такие что декодирование должно быть достаточно простым, легко параллелизуемым и локальным (что бы можно было создать специализированные чипы). Тогда как кодирование может быть в разы более трудоемким.
Остаётся надеяться только на увеличение мощности графических процессоров в будущем
Не, не будет больше увеличения мощности.
Вы правы, ведь 640 килобайт хватит всем.
Не поняли. Здесь не вопрос в том хватит — не хватит. Конечно не хватит. Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
Не поняли.
Я всё понял. А вы — не умеете в сарказм.
Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
На самом деле, может быть и хватит. Вы почему-то учитываете скорость света и расстояние, но не учитываете лоренцево сокращение длины.
Я всё понял. А вы — не умеете в сарказм.
На самом деле, может быть и хватит.
Наверное сарказмы у нас разные. Мне кажется, что и вы не так умелы. :P
У нас какой-то неудачный дуэль выходит. После каждого сообщения, вы меня минусуете. А я вас — не могу. Такое ощущение, что секундант вам выдал револьвер, а мне — палку и сказал произносить «пыщ!» при «выстреле» из неё.
Я вас не минусовал. И вообще я очень, очень редко минусую кого нибудь. И никогда как ответ на шутку или иронию.
Очень жаль, что ветка прервалась, а то я уже приготовил попкорн)
/комментарии_на_хабре_порою_интересней_поста
/комментарии_на_хабре_порою_интересней_поста
Согласен. Просто johnfound тонко шутит и не всем понятно.
А шутку я объясню:
кодеки разрабатываются для существующих наборов вычислительных инструкций, чтобы у всех быстро проигрывалось на реальных машинах. Авторы статьи такой задачи вообще не ставят. И в результате сделали кодек в сотни раз медленнее. Зато оптимизировали какой-то другой параметр на 20%.
А в конце статьи пишут
Остаётся надеяться только на увеличение мощности графических процессоров в будущем
Своим ответом
Не, не будет больше увеличения мощности.
johnfound как бы намекает, что надо делать кодек для тех вычислительных устройств которые есть сейчас.
Ну, так глубоко я не думаю и тем более не намекаю. Но понравилось.
… надо делать кодек для тех вычислительных устройств которые есть сейчас.
А вот это надо на камне вытесать и поставить на вход факультетов ИТ:
«Пиши программы для существующих компютеров, ибо в будущем смотреть тебе не дано!»
А авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будет в будущем. Было, да сплыло. Недолго музыка играла… Ну и так далее. :D
К тому же, как и другие наверх отметили, для видеокодека важно не только чтобы компрессия была выше. Дешевая декомпрессия, не побоюсь сказать, намного важнее. А с этом у авторов прямо беда какая-то — дешевая декомпрессия даже и не предвидится.
авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будетРаскрывайте карты. На чём основан прогноз? Лопнет экономический пузырь и у людей денег не будет на 11-й айфон или упрёмся в техпроцесс и тепловыделение или скорость деградации софта перевесит скорость деления ядер процессоров?
Это не прогноз. Это простое наблюдение. Экспоненциального роста уже нет. И давно. Не заметили что ли? Производительность увеличивается в лучшем случае полиномиально. И степень полинома (мне кажется) не намного больше единицы.
Чисто теоретически, энкодинг и воспроизведение видео хорошо масштабируются по ядрам. Сейчас как раз увеличением их количества и занимаются, десктопам все еще далеко до нынешних серверов, есть куда расти.
Упираемся в стоимость производства. С одной стороны, добавляешь ядра — цена растёт не линейно. C уменьшением техпроцесса количество брака тоже растёт и, в итоге, 10 нм могут оказаться дороже 30. TSMC оказывается рекламирует «древние» 500 нм.
А скорость деградации ПО не падает, увы.
А скорость деградации ПО не падает, увы.
Со всем согласен, но производительность синглкора уже почти достигла разумных пределов, крайне низкие приросты это доказывают. А вот в количестве ядер — тут еще есть, где развернуться. Не то, чтобы был выбор.
А что касается софта — в целом, особых проблем с плеерами я не заметил, производительность там не падает. В браузерах да, картина иная…
А что касается софта — в целом, особых проблем с плеерами я не заметил, производительность там не падает. В браузерах да, картина иная…
Сейчас как раз увеличением их количества и занимаются
Но не экспоненциально же! А это важно и меняет все!
А кстати, люди смотрят видео не на серверах и даже не на десктопах, а на телефонах.
А кстати, люди смотрят видео не на серверах и даже не на десктопах, а на телефонах.Да, есть такая проблема. Ну на телефонах можно ждать только AV1, никаких других (дельных) кодеков там не появится в ближайшие десять лет. Если, конечно, не произойдет какая-нибудь революция в сфере.
UFO just landed and posted this here
лоренцево сокращение длины.
И какой будет год на Земле, когда вернется с Андромеды?
Уже далеко не первый раз читаю про такие, без преувеличения скажу, гениальные, идеи, которые, казалось бы, плавают на поверхности, прям бери да делай, — но вместо этого продолжаю бежать, как белка в колесе, занимаясь какой-то околесицей для зарабатывания денег на проживание, когда хотелось бы тоже творить историю. Недавно на Хабре была статья про передачу информации от смартфона смартфону через серию QR-like кодов и камеру. Тоже просто был в восторге, насколько просто и гениально.
Что тут гениального? Тормозит всё, сжатие чуток лучше, в некоторых случаях, а где-нибудь вылезут артефакты когда переобучение какое-нибудь сработает и получите поломанную картинку.
> Недавно на Хабре была статья про передачу информации от смартфона смартфону через серию QR-like кодов и камеру.
Чтобы что?
Одного QR-кода со ссылкой на Pastebin мало что ли?
Чтобы что?
Одного QR-кода со ссылкой на Pastebin мало что ли?
IMHO, на примерах с утками создается впечатление что ML-сжатие потеряло шумовую составляющую. Утки стали выглядеть как размазанные пятна, растопыренные перья на конце крыла (в третьей строке) тоже размазало. А так, да, интересно получилось…
Ну как бы показать супер сжатие и декодирование на системе со нвидией тесла и жалкие 10 кадров в секунду — немного далековато от кодека пользовательского уровня. При таких широких лимитах нет смысла сравнивать кодеки, которые обязаны как минимум декодировать в реальном времени.
Так уж и до Pi сжатия можно добраться — есть определенная вероятность найти любой фрагмент чисел внутри числа Пи, так что можно просто хранить смещение и длину в качестве указателя на данные произвольного состава. Проблема только в расчете числа Пи до нужного количества знаков.
0.001 кадр в секунду будет на среднем офисном Intel i3 без чего бы то ни было лишнего?
так что можно просто хранить смещение и длину в качестве указателя на данные произвольного состава. Проблема только в расчете числа Пи до нужного количества знаков.
Проблема как раз таки в хранении смещения, не факт что оно окажется короче чем сами данные.
Ну как бы показать супер сжатие и декодирование на системе со нвидией тесла и жалкие 10 кадров в секунду — немного далековато от кодека пользовательского уровня.
А с чего вы взяли что это кодек пользовательского уровня? Это всего лишь научная работа на тему которая уже лет 10 как витает в воздухе.
Чтобы это стало научной работой:
1) надо сделать кодек в существующие выч. наборы инструкций
2) делать оценку качества кодека на кросс-валидации, а не на тренировочных данных.
надо сделать кодек в существующие выч. наборы инструкцийЭто какое-то особое требование научности? Они сделали на несуществующих выч инструкциях?
делать оценку качества кодека на кросс-валидации, а не на тренировочных данных.Оценка качества кодеков производилась на тестовом наборе:
We benchmark all the above codecs onлогично наверное использовать то что используется в индустрии для бенчмаркинга кодеков?
standard video test sets in SD and HD, frequently used for
evaluation of video coding algorithms. In SD, we evaluate
on a VGA resolution dataset from the Consumer Digital
Video Library (CDVL)1
. This dataset has 34 videos with a
total of 15,650 frames. In HD, we use the Xiph 1080p video
dataset2
, with 22 videos and 11,680 frames. We center-crop
all 1080p videos to height 1024 (for now, our approach requires
each dimension to be divisible by 32)
Для обучения использовались видео с ютуба:
Training data. Our training set comprises high-definition
action scenes downloaded from YouTube. We found these
work well due to their relatively undistorted nature, and
higher coding complexity. We train our model on 128×128
video crops sampled uniformly spatiotemporally, filtering
out clips which include scene cuts
Алексей, залогиньтесь!
Научно-фантастический роман Карла Сагана "Контакт" скорей вспоминал, там вокруг послания внеземного разума внутри числа Pi строился кусок сюжета :)
UFO just landed and posted this here
А для алгоритмов сжатия без ошибок это всегда так.
Рассмотрим всевозможные последовательности длины N. И алгоритм архивации A(x), преобразующий последовательность длины N в некую другую последовательность. Выходные последовательности могут быть разной длины.
Исходное множество (набор всевозможных последовательностей длины N) использует N*(n^N) знакомест, где n — число символов в алфавите. Из общих соображений ясно, что архивированное множество будет содержать никак не менее N*(n^N) знакомест. Могу доказать строго, если надо.
Иными словами, любой алгоритм часть данных переведёт в более короткие последовательности ("сжав" их), а часть — в более длинные ("надув" их). Искусство состоит в том, чтобы в каком-то смысле "полезные"/"хорошие" последовательности попали в "сжимающую" часть, а "бесполезные"/"мусорные" последовательности — в "раздувающую". Поэтому, например, обычная телевизионная "статика" обычно не сжимается, а наоборот, делается больше.
Ясно, что чем уже "сжимающая" область, тем лучшее сжатие будет в ней достигаться.
Архиватор, основанный на числе Пи, просто имеет неудачную область сжатия. Данные, которые мы обычно считаем полезными (типа картинок, музыки и проч), будут почти всегда попадать в "раздувающую" часть.
Зато само число Пи можно будет закодировать всего несколькими битами (а в пределе — всего одним)! Притом что само число Пи бесконечно, получается, что за счёт сверхузкости "сжимающего" диапазона, получается буквально бесконечная степень сжатия.
А мне понравилось про 1080p на 20% и «видео стандартного размера» на 60%.
Я считал 1080p тоже стандартным размером
Я считал 1080p тоже стандартным размером
Особенности перевода. В англоязычной среде есть определение SD и HD. SD — standard definition и HD — high definition. Имеется в виду именно это.Телевидение стандартной чёткости
Коэффициент Вайсмана кто-нибудь уже вычислил? Подозреваю что тут он будет сильно проигрывать именно из-за скорости работы.
Что насчёт AV1?
Судя по картинкам в начале статьи, новый кодек нехило так искажает информацию. Достаточно посмотреть на воду за утками, детали не просто замылены, они заменены на что-то другое.
То есть если раньше кодеки могли просто мылить картинку (выдавая это за качество), то тут высокочастотная информация вначале заменяется на нечто «похожее», но низкочастотное, а потом уже кодируется и мылится.
Не хотел бы я смотреть на мыло, хоть и в 8K.
То есть если раньше кодеки могли просто мылить картинку (выдавая это за качество), то тут высокочастотная информация вначале заменяется на нечто «похожее», но низкочастотное, а потом уже кодируется и мылится.
Не хотел бы я смотреть на мыло, хоть и в 8K.
Не знаю, где вы там замены нашли, на мой взгляд все совпадает
Почему сразу мыло, именно замена деталей, фантазия. Ну вот вам не всё равно какие перья на утке? А такая штука может их придумать, нарисовать, вплоть до всех ворсинок. Там, где важна именно точность (мелкий текст), можно точно кодировать, чтобы не надо было ничего додумывать от себя.
А такая штука может их придумать, нарисовать, вплоть до всех ворсинок.
Логично. Тогда можно и утку не снимать — пусть сам нарисует. а в видео все будет из маркеров — утка, человек, кусок булки — вообще в три байта уложится. Сценарий же типовой «кормление утки».
был такой анекдот про давних попутчиков — что анеки друг другу просто номером рассказывали. «1024!» — и все ржут. Вот это будет супер кодек.
PS. нам на ютубе в общем пофиг что утка, что лицо человека неизвестного. Можно заменять смело, включая ворсинки. ЧЧеерт, так и до новостей дойдет — представьте умный кодек дает 100500% на новостях! Палесы носят убиеннного на руках, нефть поднялась арабы вшоке, мы против войны, дом222 — знакомые все лица (сценарий типовой, 2й после утки).
Пока читал статью вспоминал формат djvu и его «Проблему «инь»». Для искажения информации при сжатии не нужно машинное обучение.
Но вообще да. Лучше уж смотреть на мыло, чем «на пупки вместо глаз», поскольку «нейросети показалось, что это пупки».
Но вообще да. Лучше уж смотреть на мыло, чем «на пупки вместо глаз», поскольку «нейросети показалось, что это пупки».
- Было бы неплохо добавить оригинальное изображение, чтобы понять насколько сжатые изображения передают детали.
- По поводу скорости работы кодеков ИМХО это весьма незначительная проблема. В следующем году подтянутся аппаратные ускорители на ПЛИС, которые позволят в десятки раз повысить скорость работы нейросетей по сравнению с GPU и тогда это не будет преградой.
Ждем новых артефактов компрессии «так показалось нейросети», когда нейросеть начинает заменять и дорисовывать одни вещи другими, потому что они выглядят похоже и в обучающей выборке все именно так.
Дык вроде была уже статья здесь про японское порно, где такие "артефакты" успешно дорисовывают то, что заботливо вырезано цензурой. :-)
Похожее уже было в ксероксах.
Вы ждете, а мы уже много лет наблюдаем.
не компрессия конечно, но уже есть такое:
i.gifer.com/2qzN.gif
i.gifer.com/2qzN.gif
С машинным обучением создали. А на блокчейне уже было?
Статья про видеокодек и ни одного видео. Нечего было показать?
Pied Piper?
В пределе это дойдет до того, что сеть просто будет строить 3Д модель сцены и всех объектов на ней, кодировать координаты и направления движений объектов и рендерить кадр рейтрейсингом?
UFO just landed and posted this here
Вот вы правильную идею выхватили — будут просто электроды в мозг подавать сигнал удовольствия, а там хоть ковёр смотри.
Особенно хорошо будут кодироваться новости. «Диктор номер два в костюме номер пять говорит вот это». Модель диктора будет браться из библиотеки, вместе с его мимикой и движениями. Возможно с уточнениями вроде «небритость такого то уровня» и «цвет лица после бурной ночи».
И фильмы каждый раз будут немного разными. Хотя это и хорошо, «ресмотребельность» повысится.
Вы сейчас описали кодер "Сценарист" и декодер "Воображение"
Вы сейчас описали скриптованные катсцены на движке игры.
Ну 3D это слишком, мне вот представляется что-то между. В начале сохраняются изображения актера со всех ракурсов, потом информация кодируется в виде «актер такой-то, угол такой-то, масштаб такой-то». Плюс мимика, плюс освещение, плюс дифф для посторонних объектов/дыма/ранений, ну и плюс контур если объекты перекрываются. Нужна только нейросеть, которая сможет это распознавать. «Словарь» в начале будет неплохо сжиматься текущими кодеками.
>> Разработчики называют нынешние методы видеокомпрессии, которые реализованы в H.265 и VP9, «древними» по стандартам современных технологий
И поэтому они создали «новейший» формат, доступный только для компьютеров будущего (возможно).
И поэтому они создали «новейший» формат, доступный только для компьютеров будущего (возможно).
UFO just landed and posted this here
UFO just landed and posted this here
«Идет медведь по лесу, видит — машина горит. Сел в нее и сгорел.»
Ну еще перед фильмом придется текстур и моделей актеров подгрузить гигабайт, но после нескольких просмотренных фильмов они все будут в кэше локально и будет побыстрее
… сжато и передано в компетентные органы.
Воскресными вечерами красно-зелено-голубые матовые стекла церковных окон вспыхивали светом и слышались голоса, поющие нумерованные церковные гимны. «А теперь споем 79. А теперь споем 94»
(с) Рэй Бредбери «Марсианские хроники»
(с) Рэй Бредбери «Марсианские хроники»
Вот у меня всегда интересовало:
Или играть в угадайку интереснее?
кодек ищет движущиеся объекты и пытается предсказать, где они будут в следующем кадре.А зачем предсказывать? Почему бы кодеку при кодировании, не «просмотреть» на несколько кадров вперёд и вместо предсказания движения (которого может и не быть, или быть но в другую сторону) зафиксировать то, которое есть на самом деле и именно это движение закодировать.
Или играть в угадайку интереснее?
Действительно, некоторые алгоритмы смотрят на будущие кадры, чтобы определить движение ещё более точно, хотя это явно не сможет работать для прямых трансляций.
Угадайка эффективнее. Обычно не более 1% кадров кодируется в видеопоток целиком. Остальные 99% «угадываются». Разумеется, с «подсказками».
Так это только в плоских мультиках объекты реально сдвигаются на экране. В фильмах плоского сдвига почти никогда нету, почти всегда присутствует либо поворот, либо приближение/отдаление от камеры, а чаще всего и то, и другое одновременно. А ещё фон под движущимся объектом на переднем плане постепенно появляется, и он тоже может двигаться по экрану, причём с другой скоростью. Поэтому самая затратная часть современных кодеков — это motion estimation, попытка угадать, какому блоку в предыдущих кадрах соответствует вот этот блок текущего кадра. Чем эффективнее работает эта часть — тем меньше разница между текущим блоком и тем, на который он ссылается, тем меньше битрейт. Собственно, по большей части пресеты veryfast-->veryslow в libx264 как раз крутят настройки motion estimation: какого размера блоки искать (от 16х16 до 4х4, кажется), нужна ли субпиксельная точность вектора движения, какой алгоритм поиска применять и т.д.
Сразу стартап Крысолов вспомнился из сериала Силиконовая долина
UFO just landed and posted this here
Вот и ответ на вопрос тем, кто кричит: «Зачем телефонам такая мощь? ее и так хватает за глаза! Лучше бы ценники уменьшали.»
Хотят тут огромной вопрос что проще и дешевле — доставить памяти (которая растет и дешевеет на глазах) и увеличить скорость Интернета (5G на подходе) или разработать достаточно мощный процессор для декодирования видео.
Хотят тут огромной вопрос что проще и дешевле — доставить памяти (которая растет и дешевеет на глазах) и увеличить скорость Интернета (5G на подходе) или разработать достаточно мощный процессор для декодирования видео.
Этот кодек (пока) не поддерживает B-frames (специальный тип кадра, который может брать информацию как из предыдущих, так и из последующих кадров исходного видео), поэтому авторы сравнивали свой кодек с H.264/H.265/VP9 с отключенными B-frames, что сильно ухудшает качество видео при одинаковом битрейте. При стандартных профилях кодирования, B-фреймы всегда используются, никто их не отключает просто так, но в их публикации упор делается на low-latency-кодирование, а B-frame'ы вносят дополнительную задержку.
Кроме того, кодирование H.264/H.265/VP9 проводилось со скоростными профилями medium и slower, в то время как более медленные профили дали бы качество выше, за счет более долгого кодирования (требуемая вычислительная мощность для декодирования изменилась бы незначительно). Их кодек выдает 10 кадров в секунду на VGA-видео (640×480) при декодировании на nVidia Tesla V100 — самой быстрой в мире видеокарте, заточенной специально под сложные вычисления (самая дешевая модель стоит 500000₽), могли бы уж хоть сравнивать с максимально возможным качеством альтернативных кодеков.
Короче, сравнение не то чтобы некорректное, но нужно понимать детали, иначе журналисты опять всех изнасилуют.
Пример с утками какой-то странный, будто использовали фильтр типа warpsharp. У H.264 деталей заметно больше.
Кроме того, кодирование H.264/H.265/VP9 проводилось со скоростными профилями medium и slower, в то время как более медленные профили дали бы качество выше, за счет более долгого кодирования (требуемая вычислительная мощность для декодирования изменилась бы незначительно). Их кодек выдает 10 кадров в секунду на VGA-видео (640×480) при декодировании на nVidia Tesla V100 — самой быстрой в мире видеокарте, заточенной специально под сложные вычисления (самая дешевая модель стоит 500000₽), могли бы уж хоть сравнивать с максимально возможным качеством альтернативных кодеков.
Короче, сравнение не то чтобы некорректное, но нужно понимать детали, иначе журналисты опять всех изнасилуют.
Пример с утками какой-то странный, будто использовали фильтр типа warpsharp. У H.264 деталей заметно больше.
Судя по заботливо прикрытым /уменьшенным разработчиками началам графиков качества (средняя ошибка по сравнению с несжатым оригиналом) на типовых используемых битрейтах новый кодек вообще НЕ ДАЕТ никакого преимущества в сжатии над современными традиционными кодеками.
Да, на битрейте скажем в 0.5 бит/пиксель и выше он конечно жмет существенно лучше (дает выше качество при том же потоке сжатых данных либо позволяет сократить поток при том же качестве). Вот только никто такие битрейты на практике сейчас не использует (а если иногда в виде исключения и использует — то с качеством тогда и так все очень хорошо, на глаз оно просто отличное — лучше уже просто некуда, отличия от несжатого оригинала там надо на компьютере выискивать и высчитывать, а на глаз при просмотре разница уже не заметна).
0.5 бит/пиксель это потоки:
31 Мбит/с для стандартного FHD видео
62 Мбит/с для FHD@60fps
125 Мбит/с для 4К
250 Мбит/с для 4К@60fps
+ поток со звуком сверху к этому
На практике сейчас для современных кодеков используются потоки примерно от 0.05 до 0.25 бит/пиксель, очень редко больше. Ютуб вообще частенько издевается и до 0.03-0.04 бит/пиксель ужимает.
А на таких потоках у кодека нет вообще нет никаких преимуществ, одни недостатки: хорошо еще если традиционным кодекам работающим в десятки раз быстрее не проиграет по качеству/сжатию:
(стрелочка на ~0.14 бит/пиксель, это например 2х часовой фильм в FHD будет весом в 8-9 ГБ)
А на потоках ниже 0.1 бит/пиксель — проиграет точно и по качеству и по скорости одновременно. Так что комментаторы выше которым не понравилась «размазня вместо утки» правы. При таких битрейтах (пример с утками 0.057 бит/пиксель) — качество хуже не только субъективно, но и объективно (при попиксельном сравнении с несжатым оригиналом и вычислении разницы).
Да, на битрейте скажем в 0.5 бит/пиксель и выше он конечно жмет существенно лучше (дает выше качество при том же потоке сжатых данных либо позволяет сократить поток при том же качестве). Вот только никто такие битрейты на практике сейчас не использует (а если иногда в виде исключения и использует — то с качеством тогда и так все очень хорошо, на глаз оно просто отличное — лучше уже просто некуда, отличия от несжатого оригинала там надо на компьютере выискивать и высчитывать, а на глаз при просмотре разница уже не заметна).
0.5 бит/пиксель это потоки:
31 Мбит/с для стандартного FHD видео
62 Мбит/с для FHD@60fps
125 Мбит/с для 4К
250 Мбит/с для 4К@60fps
+ поток со звуком сверху к этому
На практике сейчас для современных кодеков используются потоки примерно от 0.05 до 0.25 бит/пиксель, очень редко больше. Ютуб вообще частенько издевается и до 0.03-0.04 бит/пиксель ужимает.
А на таких потоках у кодека нет вообще нет никаких преимуществ, одни недостатки: хорошо еще если традиционным кодекам работающим в десятки раз быстрее не проиграет по качеству/сжатию:
(стрелочка на ~0.14 бит/пиксель, это например 2х часовой фильм в FHD будет весом в 8-9 ГБ)
А на потоках ниже 0.1 бит/пиксель — проиграет точно и по качеству и по скорости одновременно. Так что комментаторы выше которым не понравилась «размазня вместо утки» правы. При таких битрейтах (пример с утками 0.057 бит/пиксель) — качество хуже не только субъективно, но и объективно (при попиксельном сравнении с несжатым оригиналом и вычислении разницы).
31 Мбит/с для стандартного FHD видеоНа Ютубе где-то в 2-3 раза меньше, фильмы «в хорошем качестве» можно скачать с трекеров с таким битрейтом, гигов 30-40 выйдет. (H.264)
125 Мбит/с для 4КНа Ютубе в 4 раза меньше, у фильмов — в 1.5-2. (H.265)
Так что для FHD смысл еще может иметь, для фильмов, но сомневаюсь, что у консьюмерского железа хватит мощности. Плюс, если уж кодировать с такой скоростью, то у того же HEVC можно очень много настроек поменять, а не пользоваться стандартным профилем — и сильно обогнать это машинное обучение.
Да ладно, у вас какой-то собственный особый Ютуб? Потому как на обычном Ютубе не 2-3 раза, а раз в 10 меньше битрейты используются.
Вот для примера взял достаточно качественное (по меркам Ютуба) HD видео: www.youtube.com/watch?v=Bey4XXJAqS8
Кодек VP9 для видео/Opus для звука (хотя может отличаться от машины и браузера — у ютуба неск. разных версий даже для одного разрешения хранится у меня в FireFox подгрузился вариант сжатый VP9)
Померил — в FHD@30fps средний поток около 300 КБ/с (2.6 Мбит/с) причем это уже вместе со звуком.
в 4К — около 1500 КБ/с (12 Мбит/с)
Или порядка 0.04 бита на пиксель видеоизображения в обоих случаях.
Тут в статье такие битрейты даже не показали (графики обрезали снизу, начинаются где-то от 0.1 бит/пиксель только), т.к. в этом случае новый кодек проигрывает в хлам даже самым старым кодекам типа AVC(H264) и по качеству картинки и по степени сжатия(битрейту/занимаемому месту), не говоря уже и проигрыше в сотни раз по скорости/используемым выч. ресурсам.
Вот для примера взял достаточно качественное (по меркам Ютуба) HD видео: www.youtube.com/watch?v=Bey4XXJAqS8
Кодек VP9 для видео/Opus для звука (хотя может отличаться от машины и браузера — у ютуба неск. разных версий даже для одного разрешения хранится у меня в FireFox подгрузился вариант сжатый VP9)
Померил — в FHD@30fps средний поток около 300 КБ/с (2.6 Мбит/с) причем это уже вместе со звуком.
в 4К — около 1500 КБ/с (12 Мбит/с)
Или порядка 0.04 бита на пиксель видеоизображения в обоих случаях.
Тут в статье такие битрейты даже не показали (графики обрезали снизу, начинаются где-то от 0.1 бит/пиксель только), т.к. в этом случае новый кодек проигрывает в хлам даже самым старым кодекам типа AVC(H264) и по качеству картинки и по степени сжатия(битрейту/занимаемому месту), не говоря уже и проигрыше в сотни раз по скорости/используемым выч. ресурсам.
Да ладно, у вас какой-то собственный особый Ютуб? Потому как на обычном Ютубе не 2-3 раза, а раз в 10 меньше битрейты используются.И действительно, аж барские 2 МБит\с. Я ориентировался на рекомендации гугла, с какими характеристиками видео заливать.
А это видимо, чтобы был минимум потерь при двойном пережатии. Все-равно гугл залитые видео всегда пережимает в свои кодеки и со своими параметрами сжатия(и в разные сниженные разрешения разумеется — для подстройки под смотрящих), и получается что-то типа такого(на примере этого же видео):
В AVC/H264 кодеке (поток отдаваемых для клиентов не поддерживающих VP9) поток на том же видео где-то процентов на 15-20% повыше, чтобы компенсировать меньшую эффективность сжатия и получить на выходе примерно то же визуальное качество (хотя ИМХО AVC у гугла выглядит всегда хуже чем VP9, речь причем не о детализации и артефактах, у них что-то с цветопередачей — AVC какие-то более блеклые получаются).
Так лучше, если пользователь на своей стороне будет использовать самую минимальную степень сжатия. Идеально было бы конечно, вообще не сжатое заливать, но объемы и трафик в этом случае просто гигантские будут. А с указанными рекомендованными параметрами, выставленными с большим запасом это весьма близко к loss-less сжатию получается при еще вменяемых объемах и трафике.
Благодаря этому влияние подобной двойной конвертации незаметно за счет того что 2я конвертация идет с заведомо (в разы) большей степенью сжатия — тогда потерями на 1й стадии можно пренебречь. А вот если пользователь будет сразу стараться попасть примерно в тот поток, что использует Гугл — итоговое качество после 2х конвертаций окажется заметно хуже.
Format : WebM
Format version : Version 4 / Version 2
File size : 415 MiB
Duration : 29mn 36s
Overall bit rate : 1 958 Kbps
Writing application : google/video-file
Writing library : google/video-file
Video
ID : 1
Format : V_VP9
Codec ID : V_VP9
Duration : 29mn 36s
Bit rate : 1 873 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Bits/(Pixel*Frame) : 0.030
Stream size : 397 MiB (96%)
Language : English
Default : Yes
Forced : NoВ AVC/H264 кодеке (поток отдаваемых для клиентов не поддерживающих VP9) поток на том же видео где-то процентов на 15-20% повыше, чтобы компенсировать меньшую эффективность сжатия и получить на выходе примерно то же визуальное качество (хотя ИМХО AVC у гугла выглядит всегда хуже чем VP9, речь причем не о детализации и артефактах, у них что-то с цветопередачей — AVC какие-то более блеклые получаются).
Так лучше, если пользователь на своей стороне будет использовать самую минимальную степень сжатия. Идеально было бы конечно, вообще не сжатое заливать, но объемы и трафик в этом случае просто гигантские будут. А с указанными рекомендованными параметрами, выставленными с большим запасом это весьма близко к loss-less сжатию получается при еще вменяемых объемах и трафике.
Благодаря этому влияние подобной двойной конвертации незаметно за счет того что 2я конвертация идет с заведомо (в разы) большей степенью сжатия — тогда потерями на 1й стадии можно пренебречь. А вот если пользователь будет сразу стараться попасть примерно в тот поток, что использует Гугл — итоговое качество после 2х конвертаций окажется заметно хуже.
и получается что-то типа такого(на примере этого же видео):Да, я уже посмотрел выдачу mediainfo, правда она далеко не полная — неизвестны дополнительные параметры, вроде alt-frames и прочего. Интересно было бы посмотреть.
Что касается пережатия — тут проблемы будут всегда, качество в любом случае упадет, если не пытаться это фильтрами поправить\предотвратить. Но минимизировать можно, да.
Дешевле винчестер купить, чем за электричество для такого кодирования и декодирования платить.
Наверное вы хотели сказать про более дорогой интернет тариф.
По интернет-тарифу, для меня лично разницы не будет, а вот для какого-нибудь Youtube'а — может быть, сыграет роль. Им же пофиг, сколько я за электричество отдам, правда?
Вы еще храните медиафайлы локально?
Конечно, храню, и много. Помимо этого, у меня есть подписка на Netflix.
А еще у меня есть Kindle, но также полный шкаф книжек и абонемент в библиотеку.
Что вас в этом удивляет?
А еще у меня есть Kindle, но также полный шкаф книжек и абонемент в библиотеку.
Что вас в этом удивляет?
Просто я не вижу смысла хранить что-то ниже 4К — остальное проще сразу тянуть с сети.
Ой, то интернета нет, то сервер упал, то сайт заблокировали, то сидеров нет, то лицензия истекла… Я лучше по старинке, с винчестером ;)
Сейчас упорно вспоминал, когда у меня были подобные проблемы. Единственное, с чем вообще сталкивался — это сидеров нет, правда, в основном, это на всяких старых фильмах.
На этой неделе у меня отключали свет, интернета не было из-за этого полтора дня.
Пару лет назад смотрел видео с этого канала на Ютубе.
17 октября полтора часа Ютуб не работал по всему миру.
Всякое случается, по самым разным причинам.
Пару лет назад смотрел видео с этого канала на Ютубе.
17 октября полтора часа Ютуб не работал по всему миру.
Всякое случается, по самым разным причинам.
UFO just landed and posted this here
Дело в том, что поддержка HEVC исправляется расширением набора инструкций. А вот сильно ускорить машинное обучение — это большая проблема. Нужно увеличивать количество ядер.
через 2-3 года наверняка появится железная поддержка, какой-нибудь ускоритель машинного обучение
Этот кодек в 100 раз медленнее допустимого. В 100 раз увеличить количество ядер? Именно для этого кодека?
«хотя это явно не сможет работать для прямых трансляций» Но ведь очень часто допустима небольшая задержка, которая позволит алгоритму получить больше данных для сжатия перед отправкой.
Если верить первой картинке — преимущество «их» кодека — это 0,0004 бита на пиксель. Я полагаю, это еще и на один фрейм.
Окей, я помножил разрешение первого попавшегося видео с компа (1280x692 * 24 fps) и получил гигантскую экономию в 8500 байт/секунду.
Конечно затраченная на кодирование электроэнергия безусловно стоит экономии этих 8500 байт. [сарказм]
Нет, я не против развития технологий, но всерьез рассчитывать, что кодирование и декодирование видео переведут на этот новый кодек повсеместно я бы не стал. Ни в ближайшие два года, ни в ближайшие десять лет. Накладные расходы делают эту технологию совершенно нерентабельной. Даже для гиков.
Окей, я помножил разрешение первого попавшегося видео с компа (1280x692 * 24 fps) и получил гигантскую экономию в 8500 байт/секунду.
Конечно затраченная на кодирование электроэнергия безусловно стоит экономии этих 8500 байт. [сарказм]
Нет, я не против развития технологий, но всерьез рассчитывать, что кодирование и декодирование видео переведут на этот новый кодек повсеместно я бы не стал. Ни в ближайшие два года, ни в ближайшие десять лет. Накладные расходы делают эту технологию совершенно нерентабельной. Даже для гиков.
Непонятно в чем преимущество кодека перед традиционными? Отдельно взятая эффективность сжатия — это не преимущество. По сути, это равносильно сжатию в лабораторных условиях на дорогостоящем оборудовании, не в реальном времени, которое требует такого же дорогостоящего и не-реалтаймового расжатия. Было ли что-то достигнуто кодеком, что ранее было не достижимо? В 4К для передачи по гигабитной сети умеет сжимать и расжимать JPEG2000 в реалтайме, высокое качество достижимо при повышении битрейта и на H265. По сути это лабораторный образец, который предлагает пользователям установить ферму видеокарт в камеру, установить ферму видеокарт в сервер, где видео будет расжиматься ради ничтожного выигрыша в битрейте (экономии пропускной способности сети). И все это не в реалтайме. Пока что это неприемлемо ни для CCTV, ни для IPTV.
Ну дожны же мы как-то оправдать бюджеты на разработку квантовых компьютеров!
Будет забавно, если нейросеть, которая кодирует и декодирует реализована на питоне
Из того что можно найти так и есть github.com/brly/waveone
Это их прошлый кодек для изображений (но возможно не их реализация).
Это их прошлый кодек для изображений (но возможно не их реализация).
UFO just landed and posted this here
Можно пойти дальше и сразу создавать видео в таком описательном формате: «на весь кадр волны с интервалом в 20см, в середине — утка, видна по холку, смотрит влево». А дальше невообразимый простор при декомпрессии, которая уже скорее является рендерингом: и модель утки и модель волн зависит от обучения нейросети плеера.
Когда читаю подобное, то вспоминаю, как в 2002 году разрабатывали передачу видео по сети в 100 мегабит. Было что-то похожее на MJPEG. При этом видео-сервер и клиент были на одноплатниках с процессором VIA 300 МГц на Windows 2000. Естественно, с аналоговых камер не получали HD, но их было как минимум 4 для одного компа.
Сейчас даже видео с ютуба загружает Core i7 по самые помидоры.
Сейчас даже видео с ютуба загружает Core i7 по самые помидоры.
Это, конечно, здорово, что будет чем занять свежий i9, но что в итоге?!
Предсказуемость истории удручает. Дальнейшая цифровизация кино в исполнении ИИ это лишь очередной шаг в сторону отмены как такового вида искусства. Очень скоро станет очевидно, что не надо больше снимать кино, а надо делать геймификацию. Всё придёт к ролевым постановкам с накладкой лиц, габаритов и прочих характеристик актеров на заданную сюжетную линию. Можно будет посмотреть один и тот же фильм в исполнении разных актёров, не меняя всего остального. Но будет ли уже это искусство?! И будет ли оно достаточно качественным?!
То что проблемы будут — не сомневайтесь:
Такое уже проходили с копировальными аппаратами
habr.com/post/189010
Может быть даже кто-то и посмеется, когда алгоритм ошибётся и автоматически заменит Сашу Грей на Джастина Бибера. Но может пора уже начать думать в том ли направлении движется человечество подтягивая ИИ туда, где ему нет места.
Предсказуемость истории удручает. Дальнейшая цифровизация кино в исполнении ИИ это лишь очередной шаг в сторону отмены как такового вида искусства. Очень скоро станет очевидно, что не надо больше снимать кино, а надо делать геймификацию. Всё придёт к ролевым постановкам с накладкой лиц, габаритов и прочих характеристик актеров на заданную сюжетную линию. Можно будет посмотреть один и тот же фильм в исполнении разных актёров, не меняя всего остального. Но будет ли уже это искусство?! И будет ли оно достаточно качественным?!
То что проблемы будут — не сомневайтесь:
Такое уже проходили с копировальными аппаратами
habr.com/post/189010
Может быть даже кто-то и посмеется, когда алгоритм ошибётся и автоматически заменит Сашу Грей на Джастина Бибера. Но может пора уже начать думать в том ли направлении движется человечество подтягивая ИИ туда, где ему нет места.
аналогично фрактальному сжатию. там не было машинного обучения, но ассиметрия исполнения — более 1000, если память на измену не села, давно это было первая половина 90х.
декодирующий поток мал, даёт возможность прерывать его, на определенном уровне детализации, и работает сразу со всем полем изображения, в отличии от остальных методов.
Но вот кодирование, тут математики столько, что таки да, hd видео делать не стоит производить.
декодирующий поток мал, даёт возможность прерывать его, на определенном уровне детализации, и работает сразу со всем полем изображения, в отличии от остальных методов.
Но вот кодирование, тут математики столько, что таки да, hd видео делать не стоит производить.
Больше мыла богу мыла!
ИМХО с тем же успехом можно было сделать сглаживание картинки перед сжатием. Потом посжимать классическими кодеками. Какая разница, как терять детали?
ИМХО с тем же успехом можно было сделать сглаживание картинки перед сжатием. Потом посжимать классическими кодеками. Какая разница, как терять детали?
А всего лишь нужно было сделать частичное p2p при просмотре с видеохостингов. Например ролик с DASH последовательно грузится с сервера, а с конца в начало через p2p загружаются куски без DASH. В итоге и с MPEG2 могли бы жить.
Sign up to leave a comment.
Первый видеокодек на машинном обучении кардинально превзошёл все существующие кодеки, в том числе H.265 и VP9