Примеры реконструкции фрагмента видео, сжатого разными кодеками с примерно одинаковым значением BPP (бит на пиксель). Сравнительные результаты тестирования см. под катом
Исследователи из компании WaveOne утверждают, что близки к революции в области видеокомпрессии. При обработке видео высокого разрешения 1080p их новый кодек на машинном обучении сжимает видео примерно на 20%лучше, чем самые современные традиционные видеокодеки, такие как H.265 и VP9. А на видео «стандартной чёткости» (SD/VGA, 640?480) разница достигает 60%.
Разработчики называют нынешние методы видеокомпрессии, которые реализованы в H.265 и VP9, «древними» по стандартам современных технологий: «За последние 20 лет основы существующих алгоритмов сжатия видео существенно не изменились, — пишут авторы научной работы во введении своей статьи. — Хотя они очень хорошо спроектированы и тщательно настроены, но остаются жёстко запрограммированными и как таковые не могут адаптироваться к растущему спросу и всё более разностороннему спектру применения видеоматериалов, куда входят обмен в социальные СМИ, обнаружение объектов, потоковое вещание виртуальной реальности и так далее».
Применение машинного обучения должно наконец перенести технологии видеокомпрессии в 21 век. Новый алгоритм сжатия значительно превосходит существующие видеокодеки. «Насколько нам известно, это первый метод машинного обучения, который показал такой результат», — говорят они.
Основная идея сжатия видео заключается в удалении избыточных данных и замене их более коротким описанием, которое позволяет воспроизводить видео позже. Большая часть сжатия видео происходит в два этапа.
Первый этап — сжатие движения, когда кодек ищет движущиеся объекты и пытается предсказать, где они будут в следующем кадре. Затем вместо записи пикселей, связанных с этим движущимся объектом, в каждом кадре алгоритм кодирует только форму объекта вместе с направлением движения. Действительно, некоторые алгоритмы смотрят на будущие кадры, чтобы определить движение ещё более точно, хотя это явно не сможет работать для прямых трансляций.
Второй шаг сжатия удаляет другие избыточности между одним кадром и следующим. Таким образом, вместо того, чтобы записывать цвет каждого пикселя в голубом небе, алгоритм сжатия может определить область этого цвета и указать, что он не изменяется в течение следующих нескольких кадров. Таким образом, эти пиксели остаются того же цвета, пока не сказали, чтобы изменить. Это называется остаточным сжатием.
Новый подход, который представили учёные, впервые использует машинное обучение для улучшения обоих этих методов сжатия. Так, при сжатии движения методы машинного обучения команды нашли новые избыточности на основе движения, которые обычные кодеки никогда не были в состоянии обнаружить, а тем более использовать. Например, поворот головы человека из фронтального вида в профиль всегда даёт аналогичный результат: «Традиционные кодеки не смогут предсказать профиль лица исходя из фронтального вида», — пишут авторы научной работы. Напротив, новый кодек изучает эти виды пространственно-временных шаблонов и использует их для прогнозирования будущих кадров.
Другая проблема заключается в распределении доступной полосы пропускания между движением и остаточным сжатием. В некоторых сценах более важно сжатие движения, а в других остаточное сжатие обеспечивает наибольший выигрыш. Оптимальный компромисс между ними отличается от кадра к кадру.
Традиционные алгоритмы обрабатывают оба процесса отдельно друг от друга. Это означает, что нет простого способа отдать преимущество тому или другому и найти компромисс.
Авторы обходят это путём сжатия обоих сигналов одновременно и на основе сложности кадра определяют, как распределить пропускную способность между двумя сигналами наиболее эффективным способом.
Эти и другие усовершенствования позволили исследователям создать алгоритм сжатия, который значительно превосходит традиционные кодеки (см. бенчмарки ниже).
Примеры реконструкции фрагмента, сжатого разными кодеками с примерно одинаковым значением BPP показывает заметное преимущество кодека WaveOne
Карты оптического потока H.265 (слева) и кодека WaveOne (справа) на одинаковом битрейте
Однако новый подход не лишен некоторых недостатков, отмечает издание MIT Technology Review. Пожалуй, главным недостатком является низкая вычислительная эффективность, то есть время, необходимое для кодирования и декодирования видео. На платформе Nvidia Tesla V100 и на видео VGA-размера новый декодер работает со средней скоростью около 10 кадров в секунду, а кодер и вовсе со скоростью около 2 кадров в секунду. Такие скорости просто невозможно применить в прямых видеотрансляциях, да и при офлайновом кодировании материалов новый кодер будет иметь весьма ограниченную сферу использования.
Более того, скорости декодера недостаточно даже для просмотра видеоролика, сжатого этим кодеком, на обычном персональном компьютере. То есть для просмотра этих видеороликов даже в минимальном качестве SD в данный момент требуется целый вычислительный кластер с несколькими графическими ускорителями. А для просмотра видео в качестве HD (1080p) понадобится целая компьютерная ферма.
Остаётся надеяться только на увеличение мощности графических процессоров в будущем и на совершенствование технологии: «Текущая скорость не достаточна для развёртывания в реальном времени, но должна быть существенно улучшена в будущей работе», — пишут они.
Бенчмарки
В тестировании принимали участие все ведущие коммерческие кодеки HEVC/H.265, AVC/H.264, VP9 и HEVC HM 16.0 в эталонной реализации. Для первых трёх использовался Ffmpeg, а для последнего — официальная реализация. Все кодеки были максимально настроены, насколько позволили знания исследователей. Например, для удаления B-фреймов использовался H.264/5 с опцией
bframes=0, в кодеке аналогичная процедура осуществлялась настройкой -auto-alt-ref 0 -lag-in-frames 0 и так далее. Для максимизации производительности на соответствие метрике MS-SSIM, естественно, кодеки запускались с флагом -ssim.Все кодеки проверяли на стандартной базе видеороликов в форматах SD и HD, которые часто используются для оценки алгоритмов сжатия видео. Для SD-качества использовалась библиотека видео в разрешении VGA от e Consumer Digital Video Library (CDVL). Она содержит 34 видеоролика с общей длиной 15 650 кадров. Для HD использовался набор данных Xiph 1080p: 22 видеоролика общей длиной 11 680 кадров. Все видеоролики 1080p были обрезаны по центру до высоты 1024 (в данный подход нейросеть исследователей способна обрабатывать только измерения с размерностями, кратными 32 по каждой стороне).
Различные результаты тестирования показаны на диаграммах ниже:
- средние значения MS-SSIM для всех видеороликов в наборе для каждого кодека;
- сравнение размеров файла при усреднении значения MS-SSIM для всех кодеков;
- влияние различных компонентов кодека WaveOne на качество сжатия (нижняя диаграмма).
Результаты тестирования на наборе видеороликов низкого разрешения (SD)
Результаты тестирования на наборе видеороликов высокого разрешения (HD)
Влияние различных компонентов кодека WaveOne на качество сжатия
Не стоит удивляться такому высокому уровню сжатия и кардинальному превосходству над традиционными видеокодеками. Данная работа во многом основана на предыдущих научных статьях, где описываются различные методы сжатия статичных изображений на базе машинного зрения. Все они намного превосходят по уровню и качеству сжатия традиционные алгоритмы. Например, см. работы G. Toderici, S. M. O’Malley, S. J. Hwang, D. Vincent, D. Minnen, S. Baluja, M. Covell, R. Sukthankar. Variable rate image compression with recurrent neural networks, 2015; G. Toderici, D. Vincent, N. Johnston, S. J. Hwang, D. Minnen, J. Shor, M. Covell. Full resolution image compression with recurrent neural networks, 2016; J. Balle, V. Laparra, E. P. Simoncelli. End-to-end optimized image compression, 2016; N. Johnston, D. Vincent, D. Minnen, M. Covell, S. Singh, T. Chinen, S. J. Hwang, J. Shor, G. Toderici. Improved lossy image compression with priming and spatially adaptive bit rates for recurrent networks, 2017 и другие. В этих работах показано, как обученные нейросети заново изобретают многие техники сжатия изображений, которые были изобретены человеком и раньше вручную прописывались для применения традиционными алгоритмами сжатия.
Прогресс в области ML-сжатия статических изображений неизбежно привёл к появлению первых видеокодеков, основанных на машинном обучении. С увеличением производительности графических ускорителей именно реализация видеокодеков стала первым кандидатом. До настоящего момента существовала только единственная попытка создать видеокодек на машинном обучении. Она описана в работе C.-Y. Wu, N. Singhal, and P. Krahenbuhl. Video compression through image interpolation, которая опубликована в ECCV (2018). Та система сначала кодирует ключевые кадры, а затем использует иерархическую интерполяцию кадров между ними. Она демонстрирует эффективность кодирования примерно как у традиционного кодека AVC/H.264. Как видим, сейчас исследователям удалось значительно превзойти это достижение.
Статья «Выученное сжатие видео» опубликована 16 ноября 2018 года на сайте препринтов arXiv.org (arXiv:1811.06981). Авторы научной работы — Орен Риппель (Oren Rippel), Санджей Наир (Sanjay Nair), Карисса Лью (Carissa Lew), Стив Брэнсон (Steve Branson), Александер Андерсон (Alexander G. Anderson), Любомир Бурдев (Lubomir Bourdev).
Лучший комментарий Stas911:
Altaisky: Статья про видеокодек и ни одного видео. Нечего было показать?
Stas911: Они ещё декодируют первый кадр. Проявите терпение.
Комментарии (182)
SADKO
28.11.2018 14:49+2Интересно девки пляшут, однако хотелось бы подтверждений от независимых экспертов, ибо есть сильное подозрение что сеть натаскали на тестовые последовательности, что не разу не гарантирует качество и адекватность предсказаний последовательностей иных…
В скринах бросается в глаза блочность традиционных кодеков, она же плодит ошибку большую чем например у MotionJPEG2000 однако снижение битрэйта всё расставляет по своим местам.RomanArzumanyan
29.11.2018 09:58+1В скринах бросается в глаза блочность традиционных кодеков
Блочность там неспроста. Именно разбиение кадра на блоки малого размера даёт приемлемую вычислительную сложность и относительную гомогенность входного изображения в пределах малого блока. Отсюда хорошее приближение исходного изображения косинусными преобразованиями и методами меж- и внутри- кадрового предсказания.
Сравнение кодеков выглядит необъективным. Н.264/Н.265 построены вокруг В-кадров и заточены под метрику PSNR. Меж тем, В-кадры не использовались, а качество измеряли по метрике SSIM. Если авторам интересна именно эта метрика, то стоило добавить в сравнение кодек AV1. Желаю авторам удачи, но сомневаюсь что статью примут в серьёзный рецензируемый журнал.
Заголовок статьи, конечно, жёлтый. Как минимум, не хватает сравнения с AV1.Kaigorodov
29.11.2018 10:09Верно, причём современные медиа форматы очень сильно оптимизируются также под быстрое набор инструкций потребительских ПК. Создатели существующих кодеков даже не ставили такой (непрактичной) задачи, которую поставили авторы статьи.
И я думаю, что стоит применить ML для создания кодека оптимизированного под реальный набор инструкций. Только вот эта задача уже настоящая и практическая, и даже просто среднего результата будет очень сложно добиться.
erlyvideo
29.11.2018 10:45угу. Для начала хотелось бы услышать комментарии от Ясона Гаретта, потому что как правило он дает рекомендации по тому, что бы ultrafast настройки x264 поменять на что-то не столь радикальное
3Dvideo
29.11.2018 16:12+2Только добрался. Посмотрели с коллегами.
Классика жанра )))
Для начала — результаты тестирования кодеков 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 лет развития типа работают одинаково по эффективности. Но боже, кого это смущает? )))
Секрет успеха 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 ), ведь на архиве не будут задавать неприятных вопросов до публикации! )))
Всем удачи!nidalee
30.11.2018 05:33Можно вопрос по последней картинке? Каким образом у AV1 стал high encoding performance? Или я что-то не так понял? Он сейчас хоть что-то из кодеков обгоняет по скорости?
ValdikSS
30.11.2018 11:21Эта картинка из статьи, которую пишут нам из машины времени, года из 2022.
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.
nidalee
30.11.2018 12:11AV1 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 — по середине, как мне кажется, иначе ерунда какая-то выходит.ValdikSS
30.11.2018 12:44На картинке многое не соответствует действительности, не только encoding performance (хотя там имелось в виду complexity). А ниже, в decoding performance, вероятно, речь о производительности, а не сложности.
В Decoder install base VVC находится не в самом левом положении, хотя для него декодер появился, ну, пару месяцев назад, и еще не установлен ни у кого, кроме как у разработчиков этого кодека.
Я привел цитату, потому что она просто нереалистична. В цитате у человека на ноутбуке декодирование FullHD AV1 отнимает 15-20% CPU, в то время как на десктопном четырехядерном i5-4570 мой компьютер с трудом декодирует такой видеопоток чуть быстрее реалтайма (24 fps), не говоря уже о мобильных устройствах.
3Dvideo
30.11.2018 12:32У слова performance — много значений. Затрудняюсь сказать, что имели ввиду коллеги, скорее перепутано направление первой оси. AV1, как я писал выше — не просто медленный, он мучительно медленный, хотя его и ускоряют сейчас довольно эффективно.
Суммарно там в этом году в 20-100 раз ускорение (очевидно с падением эффективности) и до конца года обещают еще:
Так что чуть позднее можно будет более предметно говорить, что в итоге получилось.
Вообще средний кодек сегодня это минимум 50 квалифицированных человеко-лет, и минимум 4 гора разработки (чаще больше) и если пригнать больше людей, результат можно только ухудшить. Поэтому остается ждать и смотреть, что получается по ходу.nidalee
30.11.2018 12:43AV1, как я писал выше — не просто медленный, он мучительно медленный
Знаю, вот и удивился. Хотел его попробовать, но просто не дождался окончания процесса.
Поэтому остается ждать и смотреть, что получается по ходу.
Ну я не могу сказать, что куда-то спешу, пока HEVC вполне справляется с задачами, которые я ему ставлю. С VP9 устал воевать с колорспейсами…3Dvideo
30.11.2018 12:54Рано, рано ещё )
AV1 пока на этапе Innovators и даже о его характеристиках сложно говорить. Я уж молчу про то, что у индустрии к нему сложное отношение. Есть те, кому он сильно поможет (кто контент раздает), а железячники за голову держатся — им это в железе реализовывать… )))
xeioex
28.11.2018 15:00+1Это как сравнивать теплое с мягким.
Текущие кодеки изначально исходят не из максимальной компрессии. А из возможной компрессии с учетом ограничений (сложности и цены) декодера (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles). Поэтому в таких кодеках используются ассиметричные алгоритмы, такие что декодирование должно быть достаточно простым, легко параллелизуемым и локальным (что бы можно было создать специализированные чипы). Тогда как кодирование может быть в разы более трудоемким.
johnfound
28.11.2018 15:08Остаётся надеяться только на увеличение мощности графических процессоров в будущем
Не, не будет больше увеличения мощности.
KevlarBeaver
28.11.2018 15:11-1Вы правы, ведь 640 килобайт хватит всем.
johnfound
28.11.2018 15:18-1Не поняли. Здесь не вопрос в том хватит — не хватит. Конечно не хватит. Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
KevlarBeaver
28.11.2018 15:21-1Не поняли.
Я всё понял. А вы — не умеете в сарказм.
Вот мне например скорости света тоже не хватает, чтобы до Андромеды летать, а что поделать?
На самом деле, может быть и хватит. Вы почему-то учитываете скорость света и расстояние, но не учитываете лоренцево сокращение длины.johnfound
28.11.2018 15:42Я всё понял. А вы — не умеете в сарказм.
На самом деле, может быть и хватит.Наверное сарказмы у нас разные. Мне кажется, что и вы не так умелы. :P
KevlarBeaver
28.11.2018 16:00У нас какой-то неудачный дуэль выходит. После каждого сообщения, вы меня минусуете. А я вас — не могу. Такое ощущение, что секундант вам выдал револьвер, а мне — палку и сказал произносить «пыщ!» при «выстреле» из неё.
johnfound
28.11.2018 17:24Я вас не минусовал. И вообще я очень, очень редко минусую кого нибудь. И никогда как ответ на шутку или иронию.
TimsTims
29.11.2018 09:08+2Очень жаль, что ветка прервалась, а то я уже приготовил попкорн)
/комментарии_на_хабре_порою_интересней_постаKaigorodov
29.11.2018 10:17Согласен. Просто johnfound тонко шутит и не всем понятно.
А шутку я объясню:
кодеки разрабатываются для существующих наборов вычислительных инструкций, чтобы у всех быстро проигрывалось на реальных машинах. Авторы статьи такой задачи вообще не ставят. И в результате сделали кодек в сотни раз медленнее. Зато оптимизировали какой-то другой параметр на 20%.
А в конце статьи пишут
Остаётся надеяться только на увеличение мощности графических процессоров в будущем
Своим ответом
Не, не будет больше увеличения мощности.
johnfound как бы намекает, что надо делать кодек для тех вычислительных устройств которые есть сейчас.
johnfound
29.11.2018 11:01+1Ну, так глубоко я не думаю и тем более не намекаю. Но понравилось.
… надо делать кодек для тех вычислительных устройств которые есть сейчас.
А вот это надо на камне вытесать и поставить на вход факультетов ИТ:
«Пиши программы для существующих компютеров, ибо в будущем смотреть тебе не дано!»
А авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будет в будущем. Было, да сплыло. Недолго музыка играла… Ну и так далее. :D
К тому же, как и другие наверх отметили, для видеокодека важно не только чтобы компрессия была выше. Дешевая декомпрессия, не побоюсь сказать, намного важнее. А с этом у авторов прямо беда какая-то — дешевая декомпрессия даже и не предвидится.
rexen
29.11.2018 21:54авторы очевидно расчитывают на экспоненциальный рост производительности в будущем. А вот его и вправда уже нет и не будет
Раскрывайте карты. На чём основан прогноз? Лопнет экономический пузырь и у людей денег не будет на 11-й айфон или упрёмся в техпроцесс и тепловыделение или скорость деградации софта перевесит скорость деления ядер процессоров?johnfound
29.11.2018 23:31+1Это не прогноз. Это простое наблюдение. Экспоненциального роста уже нет. И давно. Не заметили что ли? Производительность увеличивается в лучшем случае полиномиально. И степень полинома (мне кажется) не намного больше единицы.
nidalee
30.11.2018 05:37Чисто теоретически, энкодинг и воспроизведение видео хорошо масштабируются по ядрам. Сейчас как раз увеличением их количества и занимаются, десктопам все еще далеко до нынешних серверов, есть куда расти.
batyrmastyr
30.11.2018 09:11Упираемся в стоимость производства. С одной стороны, добавляешь ядра — цена растёт не линейно. C уменьшением техпроцесса количество брака тоже растёт и, в итоге, 10 нм могут оказаться дороже 30. TSMC оказывается рекламирует «древние» 500 нм.
А скорость деградации ПО не падает, увы.nidalee
30.11.2018 12:15Со всем согласен, но производительность синглкора уже почти достигла разумных пределов, крайне низкие приросты это доказывают. А вот в количестве ядер — тут еще есть, где развернуться. Не то, чтобы был выбор.
А что касается софта — в целом, особых проблем с плеерами я не заметил, производительность там не падает. В браузерах да, картина иная…
johnfound
30.11.2018 09:56Сейчас как раз увеличением их количества и занимаются
Но не экспоненциально же! А это важно и меняет все!
А кстати, люди смотрят видео не на серверах и даже не на десктопах, а на телефонах.
nidalee
30.11.2018 12:16А кстати, люди смотрят видео не на серверах и даже не на десктопах, а на телефонах.
Да, есть такая проблема. Ну на телефонах можно ждать только AV1, никаких других (дельных) кодеков там не появится в ближайшие десять лет. Если, конечно, не произойдет какая-нибудь революция в сфере.
doctorw
29.11.2018 11:01лоренцево сокращение длины.
И какой будет год на Земле, когда вернется с Андромеды?Deerenaros
29.11.2018 15:04Почему-то меня это волнует в меньшей степени… И более того, чувства не строго негативные, а смешанные. Ну, на секунду. Я был бы не против посмотреть на человечество через 1к, 1кк, 1ккк лет.
mkshma
29.11.2018 16:56Ну разве что посмотреть и останется. Вот только общество морально и технологически может уйти так далеко, что и не нагнать будет.
KevlarBeaver
28.11.2018 15:15Уже далеко не первый раз читаю про такие, без преувеличения скажу, гениальные, идеи, которые, казалось бы, плавают на поверхности, прям бери да делай, — но вместо этого продолжаю бежать, как белка в колесе, занимаясь какой-то околесицей для зарабатывания денег на проживание, когда хотелось бы тоже творить историю. Недавно на Хабре была статья про передачу информации от смартфона смартфону через серию QR-like кодов и камеру. Тоже просто был в восторге, насколько просто и гениально.
worldmind
28.11.2018 15:50Что тут гениального? Тормозит всё, сжатие чуток лучше, в некоторых случаях, а где-нибудь вылезут артефакты когда переобучение какое-нибудь сработает и получите поломанную картинку.
KvanTTT
29.11.2018 01:58Да и простого тут тоже нет: чтобы это делать нужно будет потратить время на обучение. Не каждый программист сможет заниматься такими алгоритмами.
DimPal
28.11.2018 15:15IMHO, на примерах с утками создается впечатление что ML-сжатие потеряло шумовую составляющую. Утки стали выглядеть как размазанные пятна, растопыренные перья на конце крыла (в третьей строке) тоже размазало. А так, да, интересно получилось…
foxyrus
28.11.2018 15:54Да, но нужно учесть ограничение по битрейту (здесь спецом ограничили). Если его увеличить, думаю, нужные шумы тож появятся.
red_andr
28.11.2018 23:32+1Тоже подумалось, что если обработать хорошим шумодавом перед кодированием, то и традиционные кодеки выглядели бы также, при этом неплохо сжимали.
remzalp
28.11.2018 15:20Ну как бы показать супер сжатие и декодирование на системе со нвидией тесла и жалкие 10 кадров в секунду — немного далековато от кодека пользовательского уровня. При таких широких лимитах нет смысла сравнивать кодеки, которые обязаны как минимум декодировать в реальном времени.
Так уж и до Pi сжатия можно добраться — есть определенная вероятность найти любой фрагмент чисел внутри числа Пи, так что можно просто хранить смещение и длину в качестве указателя на данные произвольного состава. Проблема только в расчете числа Пи до нужного количества знаков.
0.001 кадр в секунду будет на среднем офисном Intel i3 без чего бы то ни было лишнего?
Tsimur_S
28.11.2018 16:10так что можно просто хранить смещение и длину в качестве указателя на данные произвольного состава. Проблема только в расчете числа Пи до нужного количества знаков.
Проблема как раз таки в хранении смещения, не факт что оно окажется короче чем сами данные.
Ну как бы показать супер сжатие и декодирование на системе со нвидией тесла и жалкие 10 кадров в секунду — немного далековато от кодека пользовательского уровня.
А с чего вы взяли что это кодек пользовательского уровня? Это всего лишь научная работа на тему которая уже лет 10 как витает в воздухе.Kaigorodov
29.11.2018 10:21Чтобы это стало научной работой:
1) надо сделать кодек в существующие выч. наборы инструкций
2) делать оценку качества кодека на кросс-валидации, а не на тренировочных данных.Tsimur_S
29.11.2018 13:11+1надо сделать кодек в существующие выч. наборы инструкций
Это какое-то особое требование научности? Они сделали на несуществующих выч инструкциях?
делать оценку качества кодека на кросс-валидации, а не на тренировочных данных.
Оценка качества кодеков производилась на тестовом наборе:
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
Virviil
29.11.2018 08:12Алексей, залогиньтесь!
remzalp
29.11.2018 15:17Научно-фантастический роман Карла Сагана "Контакт" скорей вспоминал, там вокруг послания внеземного разума внутри числа Pi строился кусок сюжета :)
DjSapsan
29.11.2018 15:51Я пропустил данный роман, но примерно понимаю в чем суть. Я сам хотел сделать алгоритм по сжатию данных в Пи. Но когда посчитал затраты, понял так даже хуже прямой передачи. Некоторым данным повезет оказаться вначале и их индекс будет маленьким, но основная масса данных потребует такой индекс, который будет экспоненциально превышать сами данные. Напишите, если я не прав :)
Assargadon
30.11.2018 09:44+2А для алгоритмов сжатия без ошибок это всегда так.
Рассмотрим всевозможные последовательности длины N. И алгоритм архивации A(x), преобразующий последовательность длины N в некую другую последовательность. Выходные последовательности могут быть разной длины.
Исходное множество (набор всевозможных последовательностей длины N) использует N*(n^N) знакомест, где n — число символов в алфавите. Из общих соображений ясно, что архивированное множество будет содержать никак не менее N*(n^N) знакомест. Могу доказать строго, если надо.
Иными словами, любой алгоритм часть данных переведёт в более короткие последовательности ("сжав" их), а часть — в более длинные ("надув" их). Искусство состоит в том, чтобы в каком-то смысле "полезные"/"хорошие" последовательности попали в "сжимающую" часть, а "бесполезные"/"мусорные" последовательности — в "раздувающую". Поэтому, например, обычная телевизионная "статика" обычно не сжимается, а наоборот, делается больше.
Ясно, что чем уже "сжимающая" область, тем лучшее сжатие будет в ней достигаться.
Архиватор, основанный на числе Пи, просто имеет неудачную область сжатия. Данные, которые мы обычно считаем полезными (типа картинок, музыки и проч), будут почти всегда попадать в "раздувающую" часть.
Зато само число Пи можно будет закодировать всего несколькими битами (а в пределе — всего одним)! Притом что само число Пи бесконечно, получается, что за счёт сверхузкости "сжимающего" диапазона, получается буквально бесконечная степень сжатия.
DjSapsan
30.11.2018 10:28Про проблему сжатия я знаю, элементарная комбинаторика. Мне было интересно, что придумал Карл Саган.
Теперь про само сжатие. На самом деле нет НИ ОДНОГО различия между данными и программой. Можно представить алгоритм сжатия любых данных в 1 бит. Все будут довольны, пока не потребуется передать другие данные. Тогда для каждых новых данных потребуется создавать новый алгоритм. Чтобы принимающий знал какие данные закодированы, ему нужно передать номер алгоритма, который раскодирует 1 бит в нужные данные. Для каждого возможного случая будет свой алгоритм. Получается, что передается номер программы, а не сами данные. В итоге это вырождается в то, что программа = данные (повторять «сжатие» можно до бесконечности).
Данные совершенно не зависят от своего отображение (дампа), данные это только программа. Так, например, можно утверждать, что два Пеинта с разными картинками это совершенно две разных программы. Рассуждать можно и дальше.
alexhott
28.11.2018 15:38+1А мне понравилось про 1080p на 20% и «видео стандартного размера» на 60%.
Я считал 1080p тоже стандартным размеромAn_private
28.11.2018 16:18+4Особенности перевода. В англоязычной среде есть определение SD и HD. SD — standard definition и HD — high definition. Имеется в виду именно это.Телевидение стандартной чёткости
AVL93
28.11.2018 15:54Коэффициент Вайсмана кто-нибудь уже вычислил? Подозреваю что тут он будет сильно проигрывать именно из-за скорости работы.
dendron
28.11.2018 16:27Судя по картинкам в начале статьи, новый кодек нехило так искажает информацию. Достаточно посмотреть на воду за утками, детали не просто замылены, они заменены на что-то другое.
То есть если раньше кодеки могли просто мылить картинку (выдавая это за качество), то тут высокочастотная информация вначале заменяется на нечто «похожее», но низкочастотное, а потом уже кодируется и мылится.
Не хотел бы я смотреть на мыло, хоть и в 8K.dipsy
28.11.2018 19:07Почему сразу мыло, именно замена деталей, фантазия. Ну вот вам не всё равно какие перья на утке? А такая штука может их придумать, нарисовать, вплоть до всех ворсинок. Там, где важна именно точность (мелкий текст), можно точно кодировать, чтобы не надо было ничего додумывать от себя.
chapai22
29.11.2018 10:51А такая штука может их придумать, нарисовать, вплоть до всех ворсинок.
Логично. Тогда можно и утку не снимать — пусть сам нарисует. а в видео все будет из маркеров — утка, человек, кусок булки — вообще в три байта уложится. Сценарий же типовой «кормление утки».
был такой анекдот про давних попутчиков — что анеки друг другу просто номером рассказывали. «1024!» — и все ржут. Вот это будет супер кодек.
PS. нам на ютубе в общем пофиг что утка, что лицо человека неизвестного. Можно заменять смело, включая ворсинки. ЧЧеерт, так и до новостей дойдет — представьте умный кодек дает 100500% на новостях! Палесы носят убиеннного на руках, нефть поднялась арабы вшоке, мы против войны, дом222 — знакомые все лица (сценарий типовой, 2й после утки).
Darth_Malok
29.11.2018 14:27Пока читал статью вспоминал формат djvu и его «Проблему «инь»». Для искажения информации при сжатии не нужно машинное обучение.
Но вообще да. Лучше уж смотреть на мыло, чем «на пупки вместо глаз», поскольку «нейросети показалось, что это пупки».
lingvo
28.11.2018 16:50- Было бы неплохо добавить оригинальное изображение, чтобы понять насколько сжатые изображения передают детали.
- По поводу скорости работы кодеков ИМХО это весьма незначительная проблема. В следующем году подтянутся аппаратные ускорители на ПЛИС, которые позволят в десятки раз повысить скорость работы нейросетей по сравнению с GPU и тогда это не будет преградой.
Paskin
28.11.2018 23:04+1Скорее сам этот алгоритм запишут в ПЛИС — потому что general-purpose ML-ускорители пока работают хорошо если в полтора раза быстрее видеокарт — и то за счет отказа от переменных (т.е. тренировать такой ускоритель не может, может только распознавать пользуясь заранее обученной сетью)
dfgwer
28.11.2018 17:10Ждем новых артефактов компрессии «так показалось нейросети», когда нейросеть начинает заменять и дорисовывать одни вещи другими, потому что они выглядят похоже и в обучающей выборке все именно так.
lingvo
28.11.2018 17:22Дык вроде была уже статья здесь про японское порно, где такие "артефакты" успешно дорисовывают то, что заботливо вырезано цензурой. :-)
Stas911
28.11.2018 19:42В пределе это дойдет до того, что сеть просто будет строить 3Д модель сцены и всех объектов на ней, кодировать координаты и направления движений объектов и рендерить кадр рейтрейсингом?
Konachan700
28.11.2018 20:16+2Нет, лучше. Будет некое символьное описание типа «3 утки на озере, вечер, сзади лес, бла-бла-бла». И по этому программа нарисует видео. Ведь нам нет разницы в большинстве случаев до того, что общие планы будут в деталях отличны от просмотра к просмотру… Сюжетка так же кодируется, только более точно и объемно. Человеческий мозг по крайней мере так может во сне делать.
Goodkat
28.11.2018 21:57+3Вот вы правильную идею выхватили — будут просто электроды в мозг подавать сигнал удовольствия, а там хоть ковёр смотри.
red_andr
29.11.2018 00:05+1Особенно хорошо будут кодироваться новости. «Диктор номер два в костюме номер пять говорит вот это». Модель диктора будет браться из библиотеки, вместе с его мимикой и движениями. Возможно с уточнениями вроде «небритость такого то уровня» и «цвет лица после бурной ночи».
unclejocker
29.11.2018 08:29Китайцы уже сделали такого диктора. На входе текст, на выходе видео. Недавно только новость была. Правда ML тут не причем, простой рендеринг и липсинк.
KvanTTT
29.11.2018 02:03+1И фильмы каждый раз будут немного разными. Хотя это и хорошо, «ресмотребельность» повысится.
roscomtheend
29.11.2018 12:06Видеокниги, результат зависит от чтеца^Wнейросети. Или, скорее, с переводчиком сравнить. Школьники Войну и Мир чтобы не читать загрузят и посмотрять на скорости 16x, вопрос только чем эту сеть обучали перед этим…
michael_vostrikov
29.11.2018 17:49Ну 3D это слишком, мне вот представляется что-то между. В начале сохраняются изображения актера со всех ракурсов, потом информация кодируется в виде «актер такой-то, угол такой-то, масштаб такой-то». Плюс мимика, плюс освещение, плюс дифф для посторонних объектов/дыма/ранений, ну и плюс контур если объекты перекрываются. Нужна только нейросеть, которая сможет это распознавать. «Словарь» в начале будет неплохо сжиматься текущими кодеками.
Dvlbug
28.11.2018 20:01+1>> Разработчики называют нынешние методы видеокомпрессии, которые реализованы в H.265 и VP9, «древними» по стандартам современных технологий
И поэтому они создали «новейший» формат, доступный только для компьютеров будущего (возможно).Stas911
28.11.2018 23:15Ну уже хорошо, что они обозначили направление движения. Сейчас в эту область пойдут деньги, умные чуваки с горящими глазами и все починят
Ndochp
29.11.2018 13:56Фракталы в эту сторону афаир уже ходили. Тоже мыло вместо квадратиков и эффективность выше по объему и ниже по произваодительности. В пром эксплуатацию с 2003 года вроде не вышли
DjSapsan
28.11.2018 21:34+4Можно представить следующий этап сжатия: нейронные сети сети распознают объекты в видео и вместо передачи каждого пикселя передают их описание. В итоге получается "(кадр 0) черная ауди, вид спереди, в позиции х, у" и т.д. Видеоплеер берет это описание и уже сам рисует пиксели.
Затем идет еще большее сжатие: нейросети распознают сюжеты в видео и пересказывают их. Например «Едет машина, потом остановилась и с нее вышел водила. Он зашел в магаз и купил колбасы». 500 МБ сжато в ~100 Б. Сжатие в 5 000 000 раз! За этим настоящее будущее!Stas911
28.11.2018 23:22Ну еще перед фильмом придется текстур и моделей актеров подгрузить гигабайт, но после нескольких просмотренных фильмов они все будут в кэше локально и будет побыстрее
vindy123
29.11.2018 11:55Воскресными вечерами красно-зелено-голубые матовые стекла церковных окон вспыхивали светом и слышались голоса, поющие нумерованные церковные гимны. «А теперь споем 79. А теперь споем 94»
(с) Рэй Бредбери «Марсианские хроники»Am0ralist
29.11.2018 12:05Или вот такРжевский пришел к Пьеру Безухову на вечеринку. Там кто-то говорит:
— Шестьдесят первый!
Взрыв смеха. Другой говорит:
— Двенадцатый!
Опять хохот. Ржевский и спрашивает у Пьера: что тут у вас за приколы?
— А это мы анекдоты рассказываем. Все их уже запомнили, чтобы каждый
раз не повторять, пронумеровали их.
Поручик встает и грит:
— Тридцать восьмой!
После неловкого молчания к нему подходит Наташа Ростова и дает пощечину.
— Но за что?!
— Здесь при дамах неприличные анекдоты не рассказывают!
yadowit
28.11.2018 21:35Вот у меня всегда интересовало:
кодек ищет движущиеся объекты и пытается предсказать, где они будут в следующем кадре.
А зачем предсказывать? Почему бы кодеку при кодировании, не «просмотреть» на несколько кадров вперёд и вместо предсказания движения (которого может и не быть, или быть но в другую сторону) зафиксировать то, которое есть на самом деле и именно это движение закодировать.
Или играть в угадайку интереснее?atap3d
28.11.2018 21:52Действительно, некоторые алгоритмы смотрят на будущие кадры, чтобы определить движение ещё более точно, хотя это явно не сможет работать для прямых трансляций.
yadowit
28.11.2018 22:08Ну почему же не может. Сквозной буфер на пяток кадров в озу и вперёд. даже при прямой трансляции, это задержка, примерно в 0,2 секунды. Не критично (имхо) — на передачу сигнала по каналам связи, задержка больше.
Insty
28.11.2018 22:01Угадайка эффективнее. Обычно не более 1% кадров кодируется в видеопоток целиком. Остальные 99% «угадываются». Разумеется, с «подсказками».
yadowit
28.11.2018 23:01Насколько я понял, в видеокодировании важна каждая мелочь. Это позволит как минимум заменить «подсказки» — «шпаргалками» и может положительно сказаться на качестве изображения.
ToSHiC
29.11.2018 00:09Так это только в плоских мультиках объекты реально сдвигаются на экране. В фильмах плоского сдвига почти никогда нету, почти всегда присутствует либо поворот, либо приближение/отдаление от камеры, а чаще всего и то, и другое одновременно. А ещё фон под движущимся объектом на переднем плане постепенно появляется, и он тоже может двигаться по экрану, причём с другой скоростью. Поэтому самая затратная часть современных кодеков — это motion estimation, попытка угадать, какому блоку в предыдущих кадрах соответствует вот этот блок текущего кадра. Чем эффективнее работает эта часть — тем меньше разница между текущим блоком и тем, на который он ссылается, тем меньше битрейт. Собственно, по большей части пресеты veryfast-->veryslow в libx264 как раз крутят настройки motion estimation: какого размера блоки искать (от 16х16 до 4х4, кажется), нужна ли субпиксельная точность вектора движения, какой алгоритм поиска применять и т.д.
eugene_bb
28.11.2018 23:46+1Непонятно только почему видеокодек, сделайте сначала замену JPEG, если всё так хорошо.
А то сразу за видео.
NIKOSV
29.11.2018 00:28Вот и ответ на вопрос тем, кто кричит: «Зачем телефонам такая мощь? ее и так хватает за глаза! Лучше бы ценники уменьшали.»
Хотят тут огромной вопрос что проще и дешевле — доставить памяти (которая растет и дешевеет на глазах) и увеличить скорость Интернета (5G на подходе) или разработать достаточно мощный процессор для декодирования видео.ValdikSS
29.11.2018 00:34На телефонах практически никогда не используется программное декодирование, слишком медленно и энергозатратно. С 2009 года во всех SoC встроены аппаратные декодеры и энкодеры. Программное декодирование применяется только для неподдерживаемых кодеков, например, для VP9 на старых устройствах.
ValdikSS
29.11.2018 00:32+3Этот кодек (пока) не поддерживает 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 деталей заметно больше.nidalee
29.11.2018 05:46Я уже не говорю о том, что у них целая гора настроек осталась, как минимум у HEVC, которые можно подкрутить: me, psy-rd…
Mad__Max
29.11.2018 04:55Судя по заботливо прикрытым /уменьшенным разработчиками началам графиков качества (средняя ошибка по сравнению с несжатым оригиналом) на типовых используемых битрейтах новый кодек вообще НЕ ДАЕТ никакого преимущества в сжатии над современными традиционными кодеками.
Да, на битрейте скажем в 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 бит/пиксель) — качество хуже не только субъективно, но и объективно (при попиксельном сравнении с несжатым оригиналом и вычислении разницы).nidalee
29.11.2018 05:5831 Мбит/с для стандартного FHD видео
На Ютубе где-то в 2-3 раза меньше, фильмы «в хорошем качестве» можно скачать с трекеров с таким битрейтом, гигов 30-40 выйдет. (H.264)
125 Мбит/с для 4К
На Ютубе в 4 раза меньше, у фильмов — в 1.5-2. (H.265)
Так что для FHD смысл еще может иметь, для фильмов, но сомневаюсь, что у консьюмерского железа хватит мощности. Плюс, если уж кодировать с такой скоростью, то у того же HEVC можно очень много настроек поменять, а не пользоваться стандартным профилем — и сильно обогнать это машинное обучение.Mad__Max
30.11.2018 02:16Да ладно, у вас какой-то собственный особый Ютуб? Потому как на обычном Ютубе не 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) и по качеству картинки и по степени сжатия(битрейту/занимаемому месту), не говоря уже и проигрыше в сотни раз по скорости/используемым выч. ресурсам.nidalee
30.11.2018 04:02Да ладно, у вас какой-то собственный особый Ютуб? Потому как на обычном Ютубе не 2-3 раза, а раз в 10 меньше битрейты используются.
И действительно, аж барские 2 МБит\с. Я ориентировался на рекомендации гугла, с какими характеристиками видео заливать.Mad__Max
01.12.2018 02:22А это видимо, чтобы был минимум потерь при двойном пережатии. Все-равно гугл залитые видео всегда пережимает в свои кодеки и со своими параметрами сжатия(и в разные сниженные разрешения разумеется — для подстройки под смотрящих), и получается что-то типа такого(на примере этого же видео):
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х конвертаций окажется заметно хуже.nidalee
01.12.2018 11:44и получается что-то типа такого(на примере этого же видео):
Да, я уже посмотрел выдачу mediainfo, правда она далеко не полная — неизвестны дополнительные параметры, вроде alt-frames и прочего. Интересно было бы посмотреть.
Что касается пережатия — тут проблемы будут всегда, качество в любом случае упадет, если не пытаться это фильтрами поправить\предотвратить. Но минимизировать можно, да.
Ogra
29.11.2018 07:06Дешевле винчестер купить, чем за электричество для такого кодирования и декодирования платить.
Kaigorodov
29.11.2018 10:32Наверное вы хотели сказать про более дорогой интернет тариф.
Ogra
29.11.2018 10:54По интернет-тарифу, для меня лично разницы не будет, а вот для какого-нибудь Youtube'а — может быть, сыграет роль. Им же пофиг, сколько я за электричество отдам, правда?
BiW
29.11.2018 12:46Вы еще храните медиафайлы локально?
Ogra
29.11.2018 13:04Конечно, храню, и много. Помимо этого, у меня есть подписка на Netflix.
А еще у меня есть Kindle, но также полный шкаф книжек и абонемент в библиотеку.
Что вас в этом удивляет?BiW
29.11.2018 14:35Просто я не вижу смысла хранить что-то ниже 4К — остальное проще сразу тянуть с сети.
Ogra
29.11.2018 14:44Ой, то интернета нет, то сервер упал, то сайт заблокировали, то сидеров нет, то лицензия истекла… Я лучше по старинке, с винчестером ;)
BiW
30.11.2018 10:56Сейчас упорно вспоминал, когда у меня были подобные проблемы. Единственное, с чем вообще сталкивался — это сидеров нет, правда, в основном, это на всяких старых фильмах.
Ogra
30.11.2018 12:47На этой неделе у меня отключали свет, интернета не было из-за этого полтора дня.
Пару лет назад смотрел видео с этого канала на Ютубе.
17 октября полтора часа Ютуб не работал по всему миру.
Всякое случается, по самым разным причинам.BiW
01.12.2018 10:18Я не спорю — все возможно, просто в моей деревне, почему-то, это все очень редко происходит, везет, наверное.
snnrman
29.11.2018 08:10Немного непонятна сноска в статье про вычислительную мощь и иронию комментариев. HEVC 4K вообще не поддерживался до 7 серии Intel (речь о процессорах), а вся обработка до этого производилась софтом, как итог — мой i7 из 2013 года не может в реальном времени показывать 4K HEVC 10b, но из 7 поколения даже Celeron способен воспроизводить без напряга этот кодек.
К чему я всё это, если стандарт реально хороший, то через 2-3 года наверняка появится железная поддержка, какой-нибудь ускоритель машинного обучение.Kaigorodov
29.11.2018 10:39Дело в том, что поддержка HEVC исправляется расширением набора инструкций. А вот сильно ускорить машинное обучение — это большая проблема. Нужно увеличивать количество ядер.
через 2-3 года наверняка появится железная поддержка, какой-нибудь ускоритель машинного обучение
Этот кодек в 100 раз медленнее допустимого. В 100 раз увеличить количество ядер? Именно для этого кодека?
SlyFox
29.11.2018 08:52«хотя это явно не сможет работать для прямых трансляций» Но ведь очень часто допустима небольшая задержка, которая позволит алгоритму получить больше данных для сжатия перед отправкой.
Arris
29.11.2018 09:18Если верить первой картинке — преимущество «их» кодека — это 0,0004 бита на пиксель. Я полагаю, это еще и на один фрейм.
Окей, я помножил разрешение первого попавшегося видео с компа (1280x692 * 24 fps) и получил гигантскую экономию в 8500 байт/секунду.
Конечно затраченная на кодирование электроэнергия безусловно стоит экономии этих 8500 байт. [сарказм]
Нет, я не против развития технологий, но всерьез рассчитывать, что кодирование и декодирование видео переведут на этот новый кодек повсеместно я бы не стал. Ни в ближайшие два года, ни в ближайшие десять лет. Накладные расходы делают эту технологию совершенно нерентабельной. Даже для гиков.
zaulan
29.11.2018 10:34Непонятно в чем преимущество кодека перед традиционными? Отдельно взятая эффективность сжатия — это не преимущество. По сути, это равносильно сжатию в лабораторных условиях на дорогостоящем оборудовании, не в реальном времени, которое требует такого же дорогостоящего и не-реалтаймового расжатия. Было ли что-то достигнуто кодеком, что ранее было не достижимо? В 4К для передачи по гигабитной сети умеет сжимать и расжимать JPEG2000 в реалтайме, высокое качество достижимо при повышении битрейта и на H265. По сути это лабораторный образец, который предлагает пользователям установить ферму видеокарт в камеру, установить ферму видеокарт в сервер, где видео будет расжиматься ради ничтожного выигрыша в битрейте (экономии пропускной способности сети). И все это не в реалтайме. Пока что это неприемлемо ни для CCTV, ни для IPTV.
zaulan
29.11.2018 10:59Будет забавно, если нейросеть, которая кодирует и декодирует реализована на питоне
lieff
29.11.2018 12:28Из того что можно найти так и есть github.com/brly/waveone
Это их прошлый кодек для изображений (но возможно не их реализация).
Sychuan
29.11.2018 17:38Учитывая, что это чисто научная работа в этом не будет ни забавного ни удивительного
unwrecker
29.11.2018 11:38Можно пойти дальше и сразу создавать видео в таком описательном формате: «на весь кадр волны с интервалом в 20см, в середине — утка, видна по холку, смотрит влево». А дальше невообразимый простор при декомпрессии, которая уже скорее является рендерингом: и модель утки и модель волн зависит от обучения нейросети плеера.
johnfound
29.11.2018 11:44А люди будут обмениваться файлами обучения. И конечно появится проект "decoder34.rules" – коефициенты для сетки, декодирующую каждый фильм в порно. :D
namikiri
29.11.2018 13:18А также появятся платные файлы с натренированными сетками. И выйдет, что нужно будет найти не только фильм, но и натренированную нейронку, которая его покажет.
WondeRu
29.11.2018 12:39Когда читаю подобное, то вспоминаю, как в 2002 году разрабатывали передачу видео по сети в 100 мегабит. Было что-то похожее на MJPEG. При этом видео-сервер и клиент были на одноплатниках с процессором VIA 300 МГц на Windows 2000. Естественно, с аналоговых камер не получали HD, но их было как минимум 4 для одного компа.
Сейчас даже видео с ютуба загружает Core i7 по самые помидоры.
FanFoul
29.11.2018 13:44-1Это, конечно, здорово, что будет чем занять свежий i9, но что в итоге?!
Предсказуемость истории удручает. Дальнейшая цифровизация кино в исполнении ИИ это лишь очередной шаг в сторону отмены как такового вида искусства. Очень скоро станет очевидно, что не надо больше снимать кино, а надо делать геймификацию. Всё придёт к ролевым постановкам с накладкой лиц, габаритов и прочих характеристик актеров на заданную сюжетную линию. Можно будет посмотреть один и тот же фильм в исполнении разных актёров, не меняя всего остального. Но будет ли уже это искусство?! И будет ли оно достаточно качественным?!
То что проблемы будут — не сомневайтесь:
Такое уже проходили с копировальными аппаратами
habr.com/post/189010
Может быть даже кто-то и посмеется, когда алгоритм ошибётся и автоматически заменит Сашу Грей на Джастина Бибера. Но может пора уже начать думать в том ли направлении движется человечество подтягивая ИИ туда, где ему нет места.
Konachan700
30.11.2018 16:27Всё хорошо. Медиажвачку будет клепать программа прямо в кинотеатре или на телевизоре пользователя, отправив на свалку истории бесполезную прослойку в виде контент-мейкеров и издателей. Контент массового потребления это не искусство ни разу, это просто бизнес, изготовление того же попсового кино мало отличается по трудозатратам от, например, вытачивания колес для вагонов на заводе…
Те же, кто делает настоящее искусство, как были, так и будут существовать, им от ИИ ни жарко ни холодно. Да они даже в плюсе останутся, ибо ИИ будет отличным инструментом при творчестве, чем в свое время стал фотошоп или ваком.
strvv
29.11.2018 13:44аналогично фрактальному сжатию. там не было машинного обучения, но ассиметрия исполнения — более 1000, если память на измену не села, давно это было первая половина 90х.
декодирующий поток мал, даёт возможность прерывать его, на определенном уровне детализации, и работает сразу со всем полем изображения, в отличии от остальных методов.
Но вот кодирование, тут математики столько, что таки да, hd видео делать не стоит производить.
Zhmak
30.11.2018 09:44Больше мыла богу мыла!
ИМХО с тем же успехом можно было сделать сглаживание картинки перед сжатием. Потом посжимать классическими кодеками. Какая разница, как терять детали?
grey_rat
01.12.2018 14:02А всего лишь нужно было сделать частичное p2p при просмотре с видеохостингов. Например ролик с DASH последовательно грузится с сервера, а с конца в начало через p2p загружаются куски без DASH. В итоге и с MPEG2 могли бы жить.
qwertyk06
Старая фраза, «чтобы фильмы смотреть можно было» обретает новую жизнь.
jrthwk
/хмыкая
Доводилось в конце 1990х держать в руках железный ускоритель для просмотра видео, который цеплялся к разъему на видяшке и таки да, реально ускорял просмотр видео.
История идет по спирали, бгг.
viiy
Voodoo2 от 3dfx же ) У меня была такая.
Voodoo 3 уже самостоятельный девайс
jrthwk
Ненене.
Это было еще до пришествия вуды, и встретилось мне только один раз. Как называлось и чье было — за давностию лет не помню совсем.
Маленькая такая платка с большим чипом, которая втыкалась в штырьковый разъем на самой видеокарте, внутри, и использовалась не для игрушек а именно для видео. Видео которое на том компе едва шевелилось с этой платкой бодро игралось во весь экран.
mambet
Что-нибудь такое, наверное.
BiW
MPEG декодер. Сам такие вживую не видел, только в западной прессе о них читал.
SRGMNV
Вот это чудо: Diamond Stealth64 Video 2001 (S3 Trio 64V+) + Diamond MVP 1100 MPEG decoder (S3 Scenic/MX2)
jrthwk
О! Именно оно, сеньк за помощь склерозу. ;)
DrPass
У меня была такая, но отнюдь не маленькая, а размером с тот же Voodoo, зато была совместима со всеми видеокартами, а не только с какой-то одной конкретной. Называлась Creative Encore Dxr3.
Fracta1L
Ну да, мой 6-летний Core i7 уже едва справляется с 4k 60 fps, а на AV1 совсем захлёбывается, сплошное дёрг-дёрг, а тут ещё хлеще кодек подвезли.
true_id1
Сдаётся мне дело не в процессоре. Мой 6 летний core i7 вполне справляется и с 8к.
ValdikSS
Если только c 8K в MPEG2.
SeeN
Дело скорее всего в видеокарте, у меня i5-2400 и gtx1060 3gb — легко запускаю 8к 60фпс на ютубе.
treegross
Всё верно — дело в видеокарте. GTX 1060 умеет в аппаратное декодирование HEVC и vp9, в результате трудится она, а процессор отдыхает.
borjomi
у меня такая же система: i5-2400, 1060 6гб, 8к 60 фпс практически не воспроизводит, 4к с подергиваением. проц нагружен на 100% видюха только на 10%. как заставить видеокарту брать задачу на себя?
nidalee
Какой браузер? Или плеер?
borjomi
браузеры: firefox, vivaldi, opera. в системе плеер от медиа плеер классик.
nidalee
В Firefox достаточно включить аппаратное ускорение в настройках. Попробуйте в Edge, там это ускорение выключить достаточно сложно.
borjomi
попробовал аппаратку в огнелисе, выбрал в настройках Максимальное число процессов контента — 7, перезагрузил браузер и разницы не заметил, кроме возросшего потребления памяти до 8гб, в моей системе 16 гб.
смотрю этот ролик www.youtube.com/watch?v=ZkofUXbwGDs
если включаю 1440, то графический проц видеокарты нагружен на 30%, если 2160, то гп нагружен на 20-25 циклично уходя в ноль. ну а в 8к вообще спит. проблему с интернетом или с буферизацией не вижу, достаточно быстро грузит ютуб.
nidalee
В Edge попробовали?
borjomi
еще нет, но сейчас этим займусь.
эм, у меня операционка винда 7, я так понял edge под нее нет?
nidalee
Да, edge под нее нет. Тогда не знаю, что вам посоветовать — можете попробовать параллельно поставить 10ку и проверить в ней, в том числе на своих стандартных браузерах. Драйвер поставить с сайта Nvidia не забудьте. На 10ке «в стоке», с драйвером, Firefox и Edge должны работать «из коробки», без каких либо настроек.
borjomi
ладно, в любом случае, благодарю за помощь.
ValdikSS
Причем тут видеокарта? Аппаратного декодирования AV1 в потребительских видеокартах не будет еще года 3 минимум.
vsb
Первые референсные реализации кодеков часто очень медленные, потом уже их сильно ускоряют, оптимизируя все узкие места, задействуя векторные инструкции и тд. Возможно в этом случае будет то же самое.
dimka11
Сомневаюсь, что это даст существенной рост производительности.
Разрешение видео, частота кадров, сложность кодеков растет, а производительность процессоров не особо.
Скорее нужна поддержка декодирования отдельными процессорами (видеокартой)
Смысла использовать универсальный центральный процессор для всех задач нет.
Раньше графика в играх обрабатывалась на CPU, позже пришли к использованию видеокарт.
eigrad
Там все вычисления уже на GPU, всё изначально векторизировано. Но как вариант для декодирования такого видео вполне можно приспособить habr.com/company/intel/blog/430492 :).