Комментарии 25
Интересно, как у него с патентами и может ли VP8 быть улучшен, чтобы обеспечивать такое же сжатие.
Это будет коммерческий или открытый проект?
Вот те раз, в моей организации оказывается над H.265 работали.
Может быть я в столовой одной вилкой ел с этим Пером.
Или из той же тарелки в другой день.
Да еще и конференция где-то здесь проходит.
А я не в курсе :(
Лошара!
Может быть я в столовой одной вилкой ел с этим Пером.
Или из той же тарелки в другой день.
Да еще и конференция где-то здесь проходит.
А я не в курсе :(
Лошара!
график доставляет: по оси Y битрейт, который непонятно откуда берется.
2-х уменьшение битрейта — это просто нереально круто, мистика просто.
Другое дело, что физически трафика все равно меньше не станет, просто поднимут разрешение )
Другое дело, что физически трафика все равно меньше не станет, просто поднимут разрешение )
Не такая уж мистика. Подозреваю, что объём вычислений при декодировании тоже возрос раза эдак в два. :) Сразу так сделать нельзя — железки не потянут. А как железо подтягивается — можно сжимать улучшенными методами. H.264 на старых компах тоже тормозил, это на современном железе он неощутим.
НЛО прилетело и опубликовало эту надпись здесь
Я не очень себе представляю, чего там такого можно насчитать, чтобы уменьшить кол-во данных в 2 раза.
Конечно, кодирование видео это не архивирование, в архивировании выше головы точно не прыгнуть.
Но все равно, сделать видеокодек, который может восстановить необходимое кол-во деталей с небольшим кол-вом искажений, используя в два раза меньше данных (учитывая что 264 и так отлично кодировал) — это действительно выдающееся достижение.
Конечно, кодирование видео это не архивирование, в архивировании выше головы точно не прыгнуть.
Но все равно, сделать видеокодек, который может восстановить необходимое кол-во деталей с небольшим кол-вом искажений, используя в два раза меньше данных (учитывая что 264 и так отлично кодировал) — это действительно выдающееся достижение.
Скорее всего всё больше методов применяется из фрактального сжатия. Когда нибудь, возможно перейдут на него. Оно крайне дорого по вычислениям, но и мощности растут.
В видео очень много повторяющейся информации переходящей из кадра в кадр.
Существующие аглоритмы сжатия видео еще даже близко не достигли предела сжатия.
Например можно представить себе алгоритм, который выделяет объекты на видео, оцифровывает их координаты и текстуры, а последовательность кадров заменяет на последовательность изменений координат, все остальное вычисляя при декодировании.
Дело все упирается в математику и в мощность оборудования.
Существующие аглоритмы сжатия видео еще даже близко не достигли предела сжатия.
Например можно представить себе алгоритм, который выделяет объекты на видео, оцифровывает их координаты и текстуры, а последовательность кадров заменяет на последовательность изменений координат, все остальное вычисляя при декодировании.
Дело все упирается в математику и в мощность оборудования.
На самом деле эта информация уже используется. Без использования информации с предыдущих (а иногда и последующего) кадров не смогли бы добиться и половины уровня сжатия современных кодеков.
А кто говорит что не используется?
Используется, но далеко не полностью, поскольку обработка идет на уровне пикселей и блоков пикселей, а не объектов.
Используется, но далеко не полностью, поскольку обработка идет на уровне пикселей и блоков пикселей, а не объектов.
И сразу встаёт вопрос, а даст ли эта информация преимущество? Описание объекта точками контура — слишком много будет занимать. Преимущество слишком сомнительно. Да, для мультов/аниме, возможно, но не для фильмов и «живого» видео.
Там по ветке выше тоже есть сомневающиеся, которые удивляются удвоению.
Если бы все сомневались и не пытались делать что-то новое мы до сих пор даже колесо не изобрели бы.
Если бы все сомневались и не пытались делать что-то новое мы до сих пор даже колесо не изобрели бы.
Казалось бы, при чём тут колесо? Вы немного не слушаете о чём я говорю. Исследования в этой области есть и естественно будут и далее.
Объект на видео характерном для фильмов и живого видео меняет не только положение. Он поворачивается, непропорционально масштабируется. Придётся разбивать его не на один, а на множество объектов. Это как векторизация фотографии. На отдельных видео (например, мультфильмы, где преобладает одноцветная основа либо градиенты) такой метод даст выигрыш с блочным методом. Но вцелом будет хуже. Я соглашусь, что расширение термина блока может оказаться полезным. Но для произвольного видео контур-основанное кодирование слишком избыточно.
В SFM (Crystal Net) так и не решили задачу выделения контура (во всяком случае не предоставляли общедосупного энкодера), хотя и так же пропагандировали, что позволит сделать хорошее качество при низком битрейте.
PS а по поводу удвоения — чистая реклама и не более. Пока не будет семплов, какое качство использовалось. Понятно, что удвоение для low bitrate — это одни задачи (видеообщение в первую очередь), а для high bitrate — совсем другие (фильмы высокого разрешения).
Объект на видео характерном для фильмов и живого видео меняет не только положение. Он поворачивается, непропорционально масштабируется. Придётся разбивать его не на один, а на множество объектов. Это как векторизация фотографии. На отдельных видео (например, мультфильмы, где преобладает одноцветная основа либо градиенты) такой метод даст выигрыш с блочным методом. Но вцелом будет хуже. Я соглашусь, что расширение термина блока может оказаться полезным. Но для произвольного видео контур-основанное кодирование слишком избыточно.
В SFM (Crystal Net) так и не решили задачу выделения контура (во всяком случае не предоставляли общедосупного энкодера), хотя и так же пропагандировали, что позволит сделать хорошее качество при низком битрейте.
PS а по поводу удвоения — чистая реклама и не более. Пока не будет семплов, какое качство использовалось. Понятно, что удвоение для low bitrate — это одни задачи (видеообщение в первую очередь), а для high bitrate — совсем другие (фильмы высокого разрешения).
В HEVC стало в 4 раза больше интра-предикшнов (предсказаний внутри текущего кадра) по сравнению с h.264/AVC: вместо 9 различных направлений предсказания — 36.
+ Больший размер макроблока (было 16х16), теперь поддерживаются до 64х64, то есть, если блок 64х64 примерно однородный, то после ДПФ и энтропийного кодирования он будет занимать чуть больше памяти, чем однородный блок размера 16х16 в h.264. Таким образом 1 блок против 16 — ощутимый перевес.
+ Motion Compensation с большей точностью — это, конечно, один из основных ударов по производительности, но аппаратные энкодеры/декодеры будут справляться, а там и программные подоспеют :)
Это, разумеется, далеко не все нововведения.
+ Больший размер макроблока (было 16х16), теперь поддерживаются до 64х64, то есть, если блок 64х64 примерно однородный, то после ДПФ и энтропийного кодирования он будет занимать чуть больше памяти, чем однородный блок размера 16х16 в h.264. Таким образом 1 блок против 16 — ощутимый перевес.
+ Motion Compensation с большей точностью — это, конечно, один из основных ударов по производительности, но аппаратные энкодеры/декодеры будут справляться, а там и программные подоспеют :)
Это, разумеется, далеко не все нововведения.
Сколько ядер должно быть на телефоне, чтобы декодировать такое видео?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Представлен стандарт сжатия видео MPEG H.265