Представлен стандарт сжатия видео MPEG H.265

    Международная организация Moving Picture Experts Group (MPEG) на конференции в Стокгольме представила черновик нового стандарта сжатия видео H.265/HEVC.

    Новый кодек обеспечивает такое же визуальное качество, что и нынешний H.264/AVC, при вдвое меньшем битрейте, сказано в пресс-релизе.

    H.265 (он же High Efficiency Video Coding или HEVC) будет использоваться, в первую очередь, для передачи видео в мобильных сетях, а также для телевизионного сигнала. Учитывая, что доля видеоконтента в общем мировом трафике к 2015 году может вырасти до 90%, улучшение сжатия в два раза — очень полезная вещь.

    Специалист Ericsson Research и председатель шведской группы MPEG Пер Фрёйд (Per Fröjdh) выражает надежду, что H.265 можно запустить в коммерческое использование уже в 2013 году.

    К 2014 году MPEG обещает принять стандарт для компрессии 3D-видео.

    Интересно, что несколько лет назад Motorola выпустила исследование (pdf), посвящённое влиянию видеоконтента на пропускную способность сетей LTE. В нём они опубликовали график с эволюцией видеокодеков, в соответствии с которым качество сжатия видео удваивается каждые 6-8 лет в результате появления более эффективных методов кодирования.

    Поддержать автора
    Поделиться публикацией

    Комментарии 25

      +3
      Интересно, как у него с патентами и может ли VP8 быть улучшен, чтобы обеспечивать такое же сжатие.
        +10
        Судя по тому, что стандарт MPEG, и он наверняка основан на H.264, стандарт будет обложен патентами по самое некуда.
        +1
        Это будет коммерческий или открытый проект?
          +3
          Скорее правильный вопрос: защищены ли алгоритмы патентами? Если нет, то открытый проект можете создать сами.
            +2
            Естественно защищены, разработку надо отбивать. Впрочем, условия лицензирования пока неизвестны, да и большинство заинтересованных сторон уже в доле (из крупняка туда только Google не входит).
            +2
            Сильно сомневаюсь, что обойдётся без патентов.
            –12
            Вот те раз, в моей организации оказывается над H.265 работали.
            Может быть я в столовой одной вилкой ел с этим Пером.
            Или из той же тарелки в другой день.
            Да еще и конференция где-то здесь проходит.
            А я не в курсе :(
            Лошара!
              +16
              А я с Эйнштейном одной водой умывался…
              +2
              график доставляет: по оси Y битрейт, который непонятно откуда берется.
                +7
                2-х уменьшение битрейта — это просто нереально круто, мистика просто.
                Другое дело, что физически трафика все равно меньше не станет, просто поднимут разрешение )
                  +2
                  Не такая уж мистика. Подозреваю, что объём вычислений при декодировании тоже возрос раза эдак в два. :) Сразу так сделать нельзя — железки не потянут. А как железо подтягивается — можно сжимать улучшенными методами. H.264 на старых компах тоже тормозил, это на современном железе он неощутим.
                    0
                    Ну как, даже на новом айпаде ощутим. Если, кажется, без аппаратно ускоряемого профиля baseline.
                      +4
                      Я не очень себе представляю, чего там такого можно насчитать, чтобы уменьшить кол-во данных в 2 раза.
                      Конечно, кодирование видео это не архивирование, в архивировании выше головы точно не прыгнуть.
                      Но все равно, сделать видеокодек, который может восстановить необходимое кол-во деталей с небольшим кол-вом искажений, используя в два раза меньше данных (учитывая что 264 и так отлично кодировал) — это действительно выдающееся достижение.

                        +1
                        Скорее всего всё больше методов применяется из фрактального сжатия. Когда нибудь, возможно перейдут на него. Оно крайне дорого по вычислениям, но и мощности растут.
                          +1
                          В видео очень много повторяющейся информации переходящей из кадра в кадр.
                          Существующие аглоритмы сжатия видео еще даже близко не достигли предела сжатия.

                          Например можно представить себе алгоритм, который выделяет объекты на видео, оцифровывает их координаты и текстуры, а последовательность кадров заменяет на последовательность изменений координат, все остальное вычисляя при декодировании.

                          Дело все упирается в математику и в мощность оборудования.
                            0
                            На самом деле эта информация уже используется. Без использования информации с предыдущих (а иногда и последующего) кадров не смогли бы добиться и половины уровня сжатия современных кодеков.
                              0
                              А кто говорит что не используется?
                              Используется, но далеко не полностью, поскольку обработка идет на уровне пикселей и блоков пикселей, а не объектов.
                                0
                                И сразу встаёт вопрос, а даст ли эта информация преимущество? Описание объекта точками контура — слишком много будет занимать. Преимущество слишком сомнительно. Да, для мультов/аниме, возможно, но не для фильмов и «живого» видео.
                                  –1
                                  Там по ветке выше тоже есть сомневающиеся, которые удивляются удвоению.
                                  Если бы все сомневались и не пытались делать что-то новое мы до сих пор даже колесо не изобрели бы.
                                    0
                                    Казалось бы, при чём тут колесо? Вы немного не слушаете о чём я говорю. Исследования в этой области есть и естественно будут и далее.
                                    Объект на видео характерном для фильмов и живого видео меняет не только положение. Он поворачивается, непропорционально масштабируется. Придётся разбивать его не на один, а на множество объектов. Это как векторизация фотографии. На отдельных видео (например, мультфильмы, где преобладает одноцветная основа либо градиенты) такой метод даст выигрыш с блочным методом. Но вцелом будет хуже. Я соглашусь, что расширение термина блока может оказаться полезным. Но для произвольного видео контур-основанное кодирование слишком избыточно.
                                    В SFM (Crystal Net) так и не решили задачу выделения контура (во всяком случае не предоставляли общедосупного энкодера), хотя и так же пропагандировали, что позволит сделать хорошее качество при низком битрейте.

                                    PS а по поводу удвоения — чистая реклама и не более. Пока не будет семплов, какое качство использовалось. Понятно, что удвоение для low bitrate — это одни задачи (видеообщение в первую очередь), а для high bitrate — совсем другие (фильмы высокого разрешения).
                            0
                            В HEVC стало в 4 раза больше интра-предикшнов (предсказаний внутри текущего кадра) по сравнению с h.264/AVC: вместо 9 различных направлений предсказания — 36.
                            + Больший размер макроблока (было 16х16), теперь поддерживаются до 64х64, то есть, если блок 64х64 примерно однородный, то после ДПФ и энтропийного кодирования он будет занимать чуть больше памяти, чем однородный блок размера 16х16 в h.264. Таким образом 1 блок против 16 — ощутимый перевес.
                            + Motion Compensation с большей точностью — это, конечно, один из основных ударов по производительности, но аппаратные энкодеры/декодеры будут справляться, а там и программные подоспеют :)

                            Это, разумеется, далеко не все нововведения.
                        +2
                        Сколько ядер должно быть на телефоне, чтобы декодировать такое видео?
                          +14
                          16-ти хватит заглаза :)
                            +2
                            Одного ASIC хватит.
                              0
                              — 640 ядер хватит каждому!

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое