Про сжатие видео — Введение

Идут дни, требования к качеству видео постоянно растут. При этом ширина каналов и емкость носителей не могла бы поспевать за этим ростом, если бы не совершенствовались алгоритмы сжатия видео.
Далее пойдет речь именно о некоторых базовых понятиях сжатия видео. Некоторые из них несколько устарели или описаны слишком просто, но при этом дают минимальное представление о том, как все работает.

image
Поиск векторов движения для компенсации движения (-: Об этом далее...

Характеристики видеопотока


Практически все знают, что любое видео – это множество статичных картинок, которые сменят друг друга во времени. Далее это упорядоченное множество мы будем называть видеопотоком. Они бывают разными, поэтому здесь крайне полезно провести небольшую классификацию:
  • Формат пикселя. Пиксель не дает нам никакой информации кроме его цвета. Однако восприятие цвета сильно субъективно и были приложены большие усилия для создания систем цветопредставления и цветопередачи, которые были бы приемлемы для большинства людей. Так цвет, видимый нами в реальном мире, является достаточно сложным по спектру частот света, что передать его в цифровом виде крайне сложно, а отобразить еще сложней. Однако было замечено, что все тремя точками в спектре можно достаточно точно приблизить отображаемый цвет к настоящему в метрике восприятия цвета обычным человеком. Эти три точки: красный, зеленый и синий. То есть их линейной комбинацией мы можем покрыть большую часть видимого спектра цветов. Поэтому самый простой способ представления пикселя: RGB24, где под компоненты Red, Green и Blue отводится ровно по 8 бит информации. И так мы можем передать 256 градаций каждого цвета и всего 16,777,216 всевозможных оттенков. Но на практике при хранении такое цветопредставление практически не используется, не только потому что мы тратим целых 3 байта на пиксель, но и по другим причинам, но об этом позже (про YV12).
  • Размер кадра. Мы уже взяли и закодировали все пиксели видеопотока и получили огромный массив данных, но он неудобен в работе. Поначалу все очень просто, кадр характеризуется: шириной, высотой, размерами видимой части и форматом (об этом чуть позже). Тут наверняка многим покажутся знакомыми цифры: 640x480, 720x480, 720x576, 1280x720, 1920x1080. Почему? Да потому что, они фигурируют в разных стандартах, например разрешение 720x576 имеет большая часть европейских DVD. Нет, конечно, можно сделать видео размером 417x503, но не думаю, что в этом будет что-то хорошее.
  • Формат кадра. Даже зная размеры кадра, мы не можем представить массив пикселей в более удобной форме, не имея информации о способе “упаковки” кадра. В простейшем случае ничего хитрого: берем строку пикселей и выписываем подряд биты каждого закодированного пикселя и так строчку за строчкой. То есть выписываем столько строк, сколько у нас высота по столько пикселей, сколько у нас ширина и все подряд, по порядку. Такая развертка называется прогрессивной (Progressive). Но может быть вы пытались смотреть телепередачи на компьютере без должных настроек и видели “эффект гребенки”, это когда один и тот же объект находится в разных положениях относительно четных и нечетных строк. Можно очень долго спорить о целесообразности чересстрочной (Interlaced) развертки, но факт, что она осталась как пережиток прошлого от традиционного телевидения (кому интересно почитайте про устройство кинескопа). Про методы устранения (деинтерлейсинга) этого неприятного эффекта сейчас говорить не буду. Отсюда и исходят магические обозначения: 576i, 720p, 1080i, 1080p, где указано количество строк (высота кадра) и тип развертки.
  • Частота кадров. Одни из стандартных значений: 23.976, 24, 25 и 29.97 кадров в секунду. Например, 25 к/с используется в европейском телевидении, 29.97 в американском, а с частотой 24 к/с снимают на кинопленку. Но откуда взялись “странные” 23.976 и 29.97? Открою секрет: 23.976 = 24/1.001, а 29.97 = 30/1.001, то есть в стандарт американского телевещания NTSC заложен делитель 1.001. Соответственно при показе киноленты произойдет совсем небольшое замедление, которое не будет заметно зрителю, но если это музыкальный концерт, то скорость показа настолько критична, что лучше изредка пропускать кадры и опять же зритель ничего не заметит. Хотя я немного обманул, по американскому телевизору никогда не показывается “24” кадра в секунду, а показывается “30” чересстрочных кадров (и того 59.94 полукадра в секунду, что соответствует частоте их электросети), но они получаются “методом спуска” (3:2 pulldown). Суть метода состоит в том, что у нас есть 2 полных кадра и 5 полукадров, и мы информацией из первого кадра заполним первые 3 полукадра, а из второго оставшиеся 2. То есть последовательность полукадров такова: [1 top, 1 bottom], [1 top, 2 bottom], [2 top, 3 bottom], [3 top, 3 bottom], [4 top, 4 bottom] и т.д. Где top – верхние строки (поля, fields), а bottom нижние, то есть, нечетные и четные начиная сверху соответственно. Таким образом, пленочная картинка вполне смотрибельна на телевизоре, но на динамичных сценах заметны подергивания. Частота кадров может быть и переменной, но с этим связано много проблем, поэтому рассматривать этот случай не буду.
  • Глобальные характеристики. Все вышерассмотренное относится к локальным свойствам, то есть тех, которые отражаются во время воспроизведения. Но длительность видеопотока по времени, объем данных, наличие дополнительной информации, зависимости и т.п. Например: видеопоток может содержать в себе один поток, отвечающий левому глазу, а другой поток некоторым образом будет хранить информацию об отличии потока правого глаза от левого. Так можно передавать стерео видео или всенародно известное “3D”.

Почему видео нужно сжимать?


Если мы будем передавать видео несжатым, то ни на что серьезное нам не хватит ни каналов связи, ни места для хранения данных. Пусть мы имеем HD поток с характеристиками:
1920x1080p, 24 к/с, RGB24 и подсчитаем “стоимость” такого потока.
1920*1080*24*24 = 1139 Мегабит/с, а если захотим записать 90 минутный фильм, то потребуется 90*60*1139 = 750 Гигабайт! Круто? Это при том, что видео фильма изумительного качества с тем же 1920x1080p на BluRay будет занимать 20 Гб, то есть разница почти в 40 раз!
Очевидно, что видео требует сжатия, особенно учитывая то, что можно сократить размер в 40 и более раз, оставив при этом зрителя в восторге.

На чем можно сэкономить?


  • Кодирование цвета. Наверняка многие знают, что когда-то давно телевидение было черно-белым, но сегодняшнее телевидение целиком в цвете. Но черно-белый телевизор по-прежнему может показывать передачи. Дело в том, что в телесигнале яркость кодируется отдельно от цветных составляющих и представляется в формате YUV (подробнее на википедии). Где Y компонента – это яркость, а U и V – цветовые компоненты и все это вычисляется по “волшебной” формуле:
    Y = 0.299 * R + 0.587 * G + 0.114 * B
    U = -0.14713 * R - 0.28886 * G + 0.436 * B
    V = 0.615 * R - 0.51499 * G - 0.10001 * B

    Как видно, преобразование линейное и невырожденное. Следовательно, мы можем с легкостью получать обратно значения R, G и B. Допустим под хранение Y, U и V мы выделим по 8 бит, тогда было 24 бита на пиксель и так и осталось. Никакой экономии. Но человеческий глаз чувствителен к яркости, а вот к цвету он не сильно притязателен. Да и почти на всех изображениях цвета сменяют друг друга не так часто. Если мы условно разделим изображение на слои Y, U и V и яркостный слой оставим без изменений, а слои U и V в два раза сократим по высоте и в два раза по ширине и того в четыре раза. Если раньше на каждый пиксель тратили 24 бита, то теперь тратим 8*4+8+8=48 бит на 4 пикселя, то есть, грубо говоря, 12 бит на пиксель (именно поэтому данный формат кодирования называется YV12). За счет цветового прореживания мы сжали поток в два раза без особых потерь. Например, JPEG всегда выполняет подобное преобразование, но по сравнению с другими возможными артефактами прореживание цвета не несет никакого вреда.
  • Избыточность изображения. Здесь особо останавливаться не буду, поскольку здесь нет никаких отличий от алгоритмов сжатия изображений. Тот же JPEG сжимает изображение за счет его локальной избыточности методами дискретного косинусного преобразования (DCT) и квантования, о чем опять же можно прочитать на википедии. Обозначу лишь то, что встроенный в кодек алгоритм сжатия статичных изображений должен хорошо сжимать даже отдаленно напоминающее реальные изображения, скоро узнаете зачем.
  • Межкадровая разность. Наверняка, любой, посмотрев любое видео, заметит, что изображения не меняются резко, а соседние кадры достаточно похожи. Конечно, резкие смены бывают, но они обычно происходят при смене сцен. И тут возникает проблема: как компьютер должен представлять все то многообразие возможных преобразований изображения? На помощь приходит алгоритм компенсации движения. Про него мной написана статья на википедии. Чтобы не производить копипаст, ограничусь лишь основными моментами. Изображение делится на блоки и в окрестности каждого из них ищется похожий блок на другом кадре (motion estimation), так получается поле векторов движения. А уже при компенсации (motion compensation) учитываются вектора движения, и создается изображение в целом похожее на исходный кадр.

    image
    Разница до компенсации движения

    image
    Разница между оригиналом и скомпенсированным кадрами

    Здесь четко видно, что исходная межкадровая разность значительно больше, чем разность между исходным и скомпенсированным кадрами. С учетом объемов информации при сжатии изображений мы можем сохранить вектора движения почти бесплатно. Сделали это и потом сжали изображение скомпенсированной межкадровой разности алгоритмом сжатия статических изображений. А так как на второй картинке откровенное месиво, то алгоритм сжатия изображений должен корректно с такими вещами работать. В силу большой избыточности таких изображений они сжимают очень сильно. Но если кодек сжимает их слишком сильно, то и возникает эффект блочности. Старые алгоритмы никак не учитывают изменения объектов по яркости и именно поэтому по телевизору видно блочность президента при вспышках фотокамер.
  • Организация последовательностей кадров. В первую очередь кодек должен быть чувствителен к смене сцен. Определить это достаточно просто, так как компенсация движения отработает в этом случае безобразно. Кадр начала новой сцены логично сохранить “как есть”, поскольку он ни на что ранее встречавшееся не похож. Такие кадры называют опорными (I-frame). А далее идут кадры, к которым применялась компенсация движения, то есть они зависят от опорного кадра и друг от друга. Это могут быть P-frame или B-frame. Первые могут опираться только на предыдущие кадры, а последние могут на левого и правого соседа. I-кадр и все его зависимые образуют GOP (group of pictures). От использования би-кадров следует насколько преимуществ: быстрая навигация (потому что предыдущие би-кадры не нужно декодировать) и то, что они имеют самый маленький размер среди всех кадров фильма, ну и немного более низкое качество (но быстрое чередование с более качественными кадрами делает это малозаметным для зрителя).
  • Избыточность выходных данных. Даже после выполнения всех сжимающих процедур поток коэффициентов имеет избыточность. Далее может применяться разные методы сжатия без потерь. В кодеке H.264, например, есть два варианта CABAC и CAVLC, реализующие арифметическое сжатие с мощной вероятностной моделью и реализующие Хаффмана с более простой моделью. ПО непонятным причинам компания Apple предпочитает последний вариант, хотя на хороших декодерах разница в быстродействии незначительна.

Вместо заключения


Я постарался рассказать некоторые базовые понятия, не сильно нагружая техническими подробностями. Далее я расскажу о структуре кодеков, контейнеров и т.д. Для тех, кто серьезно интересуется сжатием и обработкой видеоданных существует сайт compression.ru, поддерживающийся родной лабораторией компьютерной графики и мультимедиа ВМК МГУ.
Продолжение следует…
Поделиться публикацией
Комментарии 109
    +12
    Спасибо, очень интересная статья! Жду продолжения.
      +3
      Пожалуйста! В качестве продолжения будет непосредственно «цикл» видеокодека, а потом и проблемы в которые сегодня все упираются и методы их решения, предпринимаемые в нашей лаборатории в том числе.
        +2
        Хотелось бы узнать также о том чем отличаются (алгоритмы, подходы) скринкасты от видео (с точки зрения кодирования) и какими практическими подходами стоит пользоваться при созданнии программ типа «удаленный рабочий стол»
          +2
          Со скринкастами много чего проще:
          1) Нефотографичность картинки (интерфейс ОС) => легче жмется сама по себе
          2) Проще детектировать движение по векторам кандидатам (о кандидатах в следующей статье) => ровно и красивое поле векторов движения
          3) После компенсации движения разностный кадр почти весь серый

          Но есть и свои проблемы, особенно когда дело касается передачи в реальном времени. И некоторые традиционные алгоритмы могут безвозвратно испортить документальность какого-нибудь графика на мониторе.
        +2
        Да, продолжение было-бы кстати, интересуют вещи которые получены практическим путем :-)

        +1
        спасибо, очень интересно. Жду следующую статью с нетерпнием.
          –2
          Меня аж передернуло от 1го скриншота, но статья интересная!
            +7
            Ну думаю от этого скриншота вас передернуло бы не меньше))
            image
              –1
              Это точно)))
                –1
                я вообще то про «лицо» этого зверя…
              +1
              Мне первый скрин напомнил инструмент Track Motion в Adobe After Effects
                0
                Оно примерно также выглядит, тоже отвечает за определение движения пикселей
              +1
              Спасибо, отличная статья.
                +1
                Прочитал с большим удовольствием и интересом! Спасибо! Жду продолжения!
                  +1
                  Расскажите, что такое NALU и почему они используются вместо понятных блоков?
                    0
                    Про NALU ничего не слышал. И гугл что-то тоже не сильно.
                    Можно ссылку на то, что вы имели в виду?
                      +1
                      Это вот — en.wikipedia.org/wiki/Network_Abstraction_Layer
                      Network abstraction layer unit
                        +2
                        Понял, почитаю — вникну
                        При поверхностном взгляде думаю, что это относится уже к уровню транспортировки сжатого потока (и его соответствующей упаковки), а не к самому сжатию видеопотока.
                          +2
                          Если это относится к сжатию — буду благодарен, если осветите.

                          Еще интересно описание балансировки между тремя параметрами: битрейт — качество — устойчивость к потерям в канале.

                          Конкретнее — возможно ли при зафиксированном качестве и битрейте изменять параметры сжатия/избыточности (и какие именно) кодеков H.263 и H.264 (для примера) так, чтобы при большом проценте потерь в канале качество страдало бы минимально.

                            +5
                            Это одна из интереснейших тем современности. А создание быстрых декодеров, терпимых к ошибкам — весьма нетривиальное искусство. Я пока сам не могу достаточно компетентно об этом написать. Но могу задать этот вопрос спецам в лаборатории и по наличию времени опубликовать.
                              +1
                              Вряд ли существует какое-то уникальное решение. Важно, какая задача решается, какой контент, какие задержки допустимы, и кто конечные получатели, а также насколько вероятны ошибки при передаче, и какого рода эти ошибки.

                              Как что-то более-менее общее можно рассмотреть увеличение частоты ключевых кадров. Ещё советую обратить внимание на опцию --intra-refresh у кодера x264.
                              Пост разработчика об этом: x264dev.multimedia.cx/archives/249

                              По идее, должны быть ещё какие-то механизмы добавления информации для восстановления бинарного потока в случае ошибок. Но тут я ничего не знаю.
                                0
                                Формально есть три пути «помехозащищенности» для реалтаймового видеопотока:
                                1) На уровне транспорта потока — это всякие коды исправляющие ошибки (ECC) — Рида-Соломона, БЧХ и прочее.
                                2) На уровне формирования RTP пакетов — например, кладем каждый фрейм/GOB/slice в один пакет, чтобы при потере одного пакета не портились соседние «размазанные» GOB/slice.
                                3) На уровне кодека — уменьшение размера матриц квантования для уменьшения влияния потерь блоков коэффициентов.

                                Методы 2 и 3 работают для «блочных» кодеков до H.263, а начиная от H.264, где понятие кадра/GOB заменилось NALU, эти методы становятся неэффективными.

                                Вот мне и интересно было, может чего автор и напишет по этому поводу.
                      +1
                      Спасибо, хорошая статья. Читал и познавал, так сказать)
                        +1
                        Кстати, при показе по американскому телевизору оригинальный поток 24 к/с замедляется на тысячную долю, чтоб потом частоты 3:2 совпали с 59.97 разверткой
                          +2
                          Я об этом писал
                          0
                          ой и правда, прочитал между строк…
                            +3
                            белка жжот — пара скриншотов, а какая популярность :)
                              +3
                              Белка, кстати, кажется из Big Buck Bunny.

                              А мультфильм рекомендую посмотреть, тем более он бесплатный.
                              +3
                              Открою секрет: 23.976 = 24/1.001, а 29.97 = 30/1.001, то есть в стандарт американского телевещания NTSC заложен делитель 1.001. Соответственно при показе киноленты произойдет совсем небольшое замедление, которое не будет заметно зрителю, но если это музыкальный концерт, то скорость показа настолько критична, что лучше изредка пропускать кадры и опять же зритель ничего не заметит

                              А причина, по которой ввели этот делитель? Ждал объяснения, а тут БАЦ и оборвалось. Также не очень понял пример с музыкальным концертом — скорость критична, но все равно зритель не заметит?
                              Справедливо только для американского NTSC?
                                +1
                                Насчет причины введения делителя однозначного мнения нет, но наиболее реалистичной кажется то что: в электросети США ровно 60 Гц, а старые телевизоры «моргали» в такт электросети, то частота смены кадров немного снижена для смещения синхронизации по времени. То есть чтобы телевизор не мерцал без конца, а лишь время от времени.
                                Насчет концерта, то для сохранения скорости выбрасывается часть кадров, но происходит это редко и зритель ничего не замечает.
                                С европейским PAL все намного хуже, фильмы ускоряют на 4% для европейских DVD. А вот теми же концертами прибегают к болезненным алгоритмам интерполяции частоты кадров. 24 и 25 — уже слишком большая разница, повторы кадров зритель заметит.
                                  +2
                                  То есть все фильмы ускоряются на 4%, и этого никто не замечает? А к чему эти ускорения — если давно уже отошли от черезстрочной развертки и CRT кинескопов в сторону прогрессивной и LCD? Просто стандарты?
                                    +1
                                    Да — фильмы тупо ускоряются (почти все или замедляются европейские для американцев). Именно поэтому когда к западным блюреям приделывают русские звуковые дорожки с DVD их приходится перекодировать.
                                    А против стандартов в киноиндустрии не попрешь, это сейчас уже Blu-Ray плееру без разницы какой из стандартов читать (но опять же «из стандартов»), а DVD должны быть совместимы с кинескопными телевизорами.
                                      +2
                                      А как же тогда можно посмотреть фильмы в оригинальной скорости? А то 4% как то грустно.
                                        0
                                        Можете ускорить в каком-нибудь плеере. А так вам 4% времени экономили.
                                          +4
                                          Это очень слышно на вот этих двух видео:
                                          www.youtube.com/watch?v=1l3HtodpBlU — оригинал
                                          www.youtube.com/watch?v=9HGkSjLENa4 — русская лицензия(ntsc->pal, ускорение 4%)
                                            +1
                                            Я, как любитель аниме, разницу заметил, да и вспомнил заодно сюжет, но вот рядовому пользователю, не увлекающемуся аниме, вы вынесли мозг:)
                                              +1
                                              Почему? Разве на слух не заметно? Там же тембр во втором видео выше из-за ускорения.
                                              а почему сейчас сюжет вспомнили, что, suzumiya haruhi no shoushitsu пропустили?
                                                0
                                                сразу заметил разницу, хотя ничуть не анимешник.
                                          +1
                                          а в чём заключается суть PAL или NTSC применительно к цифровому видеопотоку? разве что-то кроме частоты кадров/развёртки имеет значение?
                                          на современном (цифровом) оборудовании (не беря в расчёт ПК) картинка всё-таки воспроизводится «as is» или непременно с преобразованиями?
                                            0
                                            PAL и NTSC породили подобные цифровые стандарты.
                                            Ну приводить к 60 fps монитора то придется, все равно преобразование.
                                              0
                                              а где сказано, что у каждого экрана — 60 fps? :)
                                                0
                                                Не у каждого, но у большинства так.
                                                  0
                                                  Наверное «у большинства ЖК».
                                                  ЭЛТ работают на разных частотах, и могут переключаться в довольно широких пределех.
                                                  И, да, ими все еще пользуются. Пока цена/качество для ЖК не станет человечной.
                                              0
                                              Вообще в ntsc и pal существенно по-разному кодируется изображение именно при радиопередаче, в особенности цвет. В ntsc вообще там очень красивая математика, которая на практике, однако, показала свои проблемы и возникла получили расшифровку nevet the same color.

                                              В цифровом различаются во-первых размеры растра по вертикали (для PAL это 288 или 576 и для NTSC — 240 и 480). Это пришло из радиостандартов: PAL-625 строк, NTSC-525 строк, при этом видимых соответственно 575 и 479, и экран начинается с полу-строки (ну т.е. со строки, которая содержит изображение начиная с середины) и такой же полу-строкой заканчивается.
                                              Во-вторых различается частота кадров: для PAL допустима частота 25, для NTSC — 27.97.
                                              Другие различия уже чисто цифровые: скажем, некоторые типы pulldown не получится сделать в «чужом» стандарте, (типа 3:2, который переводит фильмы 24fps->30fps, и который имеет смысл только для PAL). На самом деле, это даже не ограничение формата, а ограничения логики кодировщика: какой-то определённый pulldown не указывается, а в потоке ставятся флаги: «поле закодировано непосредственно» или «поле является повторением другого поля», в результате чего для 3:2 фактически кодируется 24 кадра в секунду, а «добавление кадров» до 30 происходит непосредственно при распаковке потока.

                                              С появлением HD разница полностью устранена — там нет понятий «PAL» или «NTSC». Стандарты просто описываются названием профиля: разрешение картинки, частота кадров и тип потока (кадры/поля). Разнообразные соотношения сторон, которые были раньше, тоже ушли в небытие: все HD-стандарты — 16:9
                                                0
                                                Есть ошибки:
                                                29.97, а не 27.97
                                                3:2 pulldown имеет отношение только к NTSC а не к PAL как вы написали
                                                и пулдаун не всегда делается флагами в потоке, чаще это делают ДО кодирования.
                                                  0
                                                  Мда, про 3:2 для PAL — это я просто ошибся, имелось ввиду как раз «не имеет смысла для PAL»

                                                  Про «пулдаун до кодирования» — не понял, что не так? Материал вообще смешаный film/video бывает, там половину фильма флаги есть, половину — флагов нет, и как их расставить — задача кодировщика, т.е. они на этапе кодирования расставляются.
                                                    0
                                                    Не совсем. Есть два случая:
                                                    1) Кодируется 29.97 в чересстрочной разверткой и флагами показывается где уже поработал 3:2 pulldown. а где нет. А рендер в тех местах вернет обратно 23.976 и покажет все идеально, а где «чистые» 29.97 уже будет работать деинтерлейсер и качество снизится.
                                                    2) Кодируется 23.976, но флагами говорим что надо показать 29.97. Когда-то применялось на DVD.
                                                      0
                                                      Я ни разу не видел проигрывателя, которые бы для «смешанных» видео рисовал бы 23.976 для мест, где были флаги («film») и 29.97 там, где их не было («video»).
                                                      По-моему все честно получают 29.97fps-поток, возможно, с повторяющимися полями и его уже стараются показать. Если показывают на экране компа — абсолютно весь поток деинтерлейсится, даже в тех местах, где в принципе изначально это film.
                                              0
                                              А я когда заметил, что по телеку фильмы идут с повышенной скоростью, думал что они это делают, для экономии эфирного времени (впихивания больше рекламы). А оно вон как оказывается.

                                              А почему на блюреях, если им уже без разницы, используется 23.976 fps, а не 24?
                                                0
                                                На блюрее можно использовать 24. Обычно мастер-запись звука берут тупо ту что для американского DVD и все)) Но например видел фильмы IMAX на BD, где ровно 24.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1
                                                Отставить задорновщину!
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Дело не в черезстрочной развёртке, а в том, что у вас экран работает с одной частотой, а видео-поток идёт с другой. Из-за этого разные кадры проводят разное количество времени на экране. В итоге вместо плавной картинки видно дёрганное изображение. Я когда смотрю кино на компе, то у меня reclock ускоряет видео аж до 30 кадров в секунду, потому как дёрганую картинку мне смотреть неприятно.
                                                +1
                                                Частота сети здесь не причем.
                                                30/1.001 был введён при внедрении цвета в NTSC для уменьшения влияния несущей звука на цветовую поднесущую.
                                                  0
                                                  Вполне возможно. Просто документально причина нигде не закреплена.
                                                    +1
                                                    В стандарте конечно не написано «зачем», но это однозначный факт. Просто вы видимо с анологовым видео мало общались.
                                                  0
                                                  выходит, вся эта чехарда с различной частотой кадров — лишь ради совместимости с какой-то древней ЭЛТ техникой? вроде бы уже на цифровое ТВ в США переходят повсеместно, и всё равно…
                                                  25 кадров/с в Европе сугубо по той же причине применяется, из-за 50 Гц электросети?
                                                    0
                                                    Вот 25 кадров точно из-за электросети.
                                                    Но вот отснятые материалы уже никуда не денешь => стандарты не стали менять, просто современные железки показывают и то и другое.
                                                      0
                                                      ЭЛТ мониторы работают с широким диапазоном частоты. Как раз в отличие от ЖК, у которых она обычно фиксирована.
                                                  +2
                                                  Спасибо автору, не знал про цвета, прям глаза открыли :)
                                                    0
                                                    Ага, я тоже думал что ч\б телевизор просто показывает то что ловит, а кинескоп не может цвета показать )
                                                    0
                                                    Спасибо. Отдельные вещи знал, но кое-что новое подчерпнул, да и вообще здорово увидеть все собранным в одном месте и структурированным.
                                                    Насколько я помню, с арифметическим кодированием есть какие-то проблемы с лицензией, поэтому и используется хаффман.
                                                      0
                                                      Уже нет. Патент истек))
                                                        0
                                                        Тогда, видимо, по привычке :)
                                                        А давно истек? Может просто еще не успели реализовать?
                                                          0
                                                          Когда истекли не знаю. Но все патенты IBM уже истекли, остался только один патент компании Ricoh www.google.com/patents?vid=5272478
                                                          Но нынешние реализации его не нарушают.
                                                      0
                                                      Спасибо, некоторые вещи знал, но далеко не все. Жду продолжения!
                                                        +1
                                                        Небольшой вопрос по поводу подсчётов, никак не могу сообразить:
                                                        1920*1080*24*24 = 1139 Мегабит/с, а если захотим записать 90 минутный фильм, то потребуется 90*60*1139 = 750 Гигабайт!

                                                        В исходных данных у нас мегабиты, а в результате уже гигабайты. Можно небольшой ликбез по переводу этих величин? А то помню со школы, что 1 байт=8 бит, но как тут получилось, никак не соображу =/
                                                          +4
                                                          (1139 мбит / 8) * 90 мин *60 сек = 768825 Мб / 1024 = 751 Гб
                                                            +1
                                                            Спасибо, переглючило.
                                                            +2
                                                            Я опустил переводы величин:
                                                            90*60*1139 = {МБит/с * сек = МБит} = 6150600 МБит = {/8} = 768825 Мбайт = {/1024} = 750.8 Гигабайт.
                                                              +1
                                                              Да, спасибо, я тупанул.
                                                                0
                                                                Наверное зря опустил ибо выглядит как ошибка. Я тоже заметил это несоответствие и хотел обратить внимание в комментариях.
                                                              +1
                                                              Спасибо, неплохая статья. Напишите ещё про анаморфный пиксель и переменную частоту кадров.
                                                                0
                                                                Про анаморфный пиксель ничего особо интересного нет: прямоугольный он и в африке прямоугольный, кодек это не волнует, это уже забота устройства отображения.
                                                                Переменная частота кадров — зло. Но она полезна в системах видеонаблюдения. Кодек тоже не сильно частота кадров беспокоит, а вот рендеру с ней работать тяжело. Смысл в том что стоит камера, снимает в ночное время, снимает еще и шумы, а они меняются с течением времени, а других изменений нет => нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать.
                                                                  0
                                                                  нет и смысла хранить кадры в которых только меняется шум, лишь будут место занимать

                                                                  не для этого ли в большинстве систем видеонаблюдения применяются те или иные алгоритмы motion detection? нет существенного изменения — новые кадры не сохраняются
                                                                    0
                                                                    Они и есть — отсюда переменная частота кадров.
                                                                0
                                                                У нас в университете как раз был курс лекций по обработке видеосигналов, который читал Красильников Н.Н., один из прорадителей цифрового телевидения у нас. За статью спасибо, вспомнил былые годы…
                                                                  0
                                                                  acmer, вот подскажи. какие проги для конвертации умеют жать с 23.976 до 25 путем убыстрения видео? нашел в procoder'e фильтр pulldown, но сам прокодер очень медленно жмёт. Хотелось бы знать, какие галки в xilisoft video cobverter или mediacoder поставить надо. спс
                                                                    +2
                                                                    Во-первых и в основных — зачем это вам частоту кадров менять? Это совершенно ненормальная задача, могла бы возникнуть только при редактировании видео, а при просмотре вообще-то совершенно пофигу, какая там частота кадров.

                                                                    То есть, если вы просто поменять её хотите, ничего перекодировать не надо — надо взять и поменять флаг, указывающий на частоту кадров. Это можно сделать в проге ReStream, если речь о MPEG-файле или же в VirtualDubе, если речь об AVI. Для других форматов можно попробовать тот же VirtualDub, если он сможет, или virtualdubmod.
                                                                    В любом случае, придётся самостоятельно чуть ускорить звук и подменить дорожку.

                                                                    Да, и фильтр pulldown скорее всего делает совершенно другое. Он либо просто ставит периодически флажки в выходном файле, чтобы декодер показывал некоторые поля по два раза (так кодируется 24 кадра в сек, а показывается 30), либо он ещё перед этим сканирует поток, находит одинаковые поля и уже ставит флажки в зависимости от найденного (применяется для смешанного материала film/video, когда идёт то фильм-материал, для которого имеет смысл pulldown, то видео-материал, для которого pulldown смысла не имеет).
                                                                      0
                                                                      тут дело такое. у меня железка видит исключительно mpeg2 pal и никак иначе. приходиться всякие сериалы кодить с mpeg4 23.976.
                                                                        +1
                                                                        Ну, вам не повезло с железкой :(

                                                                        Но тут в любом случае перекодировать… Только вот автомат с ходу назвать затруднюсь. Точно могу сказать, что никакой pulldown не нужен.

                                                                        Я кодировал видео для DVD при помощи HCenc или CinemaCraft Encoder SP. Это не самый тривиальный подход, но кодировщики эти очень быстрые.
                                                                        HCenc бесплатный, но от вас потребуется AviSynth — он видео умеет брать только из него.

                                                                        Звуковую дорожку готовить так: распаковать, ускорить в любом редакторе (хоть audacity) в 25*1.001/24 = 1.042708(3) раза и запаковать в mpeg1 layer2 (при помощи twolame) либо в ac3 (при помощи besweet, например).

                                                                        Потом муксером собрать видео и аудио в програмный поток.
                                                                          0
                                                                          эх. радикально. а на какие контрольные фразы обращать внимание, копаясь в настройках «автоматов» нужно? pulldown отмели, как я понял.
                                                                            0
                                                                            Вы DVD-подобный (совместимый) поток хотите в итоге сделать, или железка играет любой pal mpeg2?
                                                                              0
                                                                              В общем, для PAL DVD — делайте размер картинки 720x576, ограничивайте битрейт видео 9800kbps (и на звук надо оставить, чтобы в сумме было не более 10000kbps); ещё нужно выставить правильное соотношение сторон картинки, на DVD допустимы 4:3 и 16:9. Вообще, часто есть пресет «DVD» — выбирайте его и не морочьте себе голову.
                                                                                0
                                                                                так при таком раскладе получаются рывки, раз в секунду, т.к. 25-23.976 — в это время кодер вставляет предыдущий кадр, насколько я понимаю. вот и хочется убыстрить все видео, чтобы оно было без рывков.
                                                                                  0
                                                                                  В общем, я боюсь, для такой задачи готового автомата нет. Ваш вот автомат — больно умный, кадры вставляет. Да и звук вам по-любому отдельно обрабатывать.

                                                                                  Если исходные файлы — avi, наиболее простой будет такая последовательность действий:
                                                                                  VirtualDubом открываем файл, делаем Audio->Save WAV.
                                                                                  Этот WAV подправляем в редакторе, ускоряем. Кстати, звук должен быть в итоге 48000 Гц для DVD.
                                                                                  в VirtualDubе ставим «брать звук из WAV», а в Video — меняем частоту кадров на 25 и ставим direct stream copy, после чего сохраняем всё как avi — это будет промежуточный файл.

                                                                                  Его уже скармливаем вашему автомату.

                                                                      0
                                                                      1920*1080*24*24*5400/8 = 806 215 680 000 байт ~ 750ГБ
                                                                        0
                                                                        извиняюсь, ответ был для Mairon
                                                                          +11
                                                                          Сдаюсь уже, сдаюсь =)
                                                                          0
                                                                          Когда-то давно меня занимала мысль реализовать видеокодек путем разложения каждой линии кадра в ряд Фурье с сохранением коэффициентов гармоник. Смысл примерно тот же как и в стандартных кодеках — соседние кадры как правило очень похоже и сохранять можно изменяющиеся коэффициенты гармоник.
                                                                          Но индустрия и без меня справилась и умудряется запихнуть 1080р фильм в 10-15 ГБ!

                                                                          Хотя я бы с удовольствием почитал про предложенный метод, если его кто-то пытался делать.
                                                                          Автору топика известны работы в этой области?

                                                                            0
                                                                            > Хотя я бы с удовольствием почитал про предложенный метод, если его кто-то пытался делать.
                                                                            > Автору топика известны работы в этой области?
                                                                            ШТО? Поставим вопрос так: кто из разработчиков всех действующих кодеков НЕ проводил работы в этой области?
                                                                              0
                                                                              Простите, невнимательно прочел комментарий.
                                                                              0
                                                                              Эта область сейчас занята немного другими делами, я именно — 3D
                                                                              Поэтому и проект интела по применению вейвлетов (про них я знаю очень мало) к видео почти не движется. H.264 очень хорошо справляется с поставленной задачей, но с 3D пока у него проблемы.
                                                                              А приведенный в статье метод (естественно более сложный) реализован в XviD
                                                                                0
                                                                                Касательно вейвлетов — уже лет как 5 существуют быстрые и тупые вйевлет-кодеки для видеоконференцсвязи. Они дают хреновое качество, но быстры, просты и часто используются в локальных сетях.
                                                                                  +1
                                                                                  Вот вейвлеты — очень вычислительно жадные. Да они используются, но на оочень маленьких битрейтах (с очень херовым качеством), потому что иначе уже никак. Но по сравнению с обычными кодеками быстротой они не отличаются.
                                                                              0
                                                                              Вау, очень познавательно )
                                                                              Хоть и болван в математике, но общая теория очень понравилась.
                                                                              Жду продолжение, спасибо
                                                                                0
                                                                                О! Отличная тема! Автор, подскажите пожалуйста, а если бы я допустим хотел провести тесты разных кодеков по сжатию видео, как лучше всего посчитать (автоматически) уровень потерь качества? не отсматривать же вручную десятки видеороликов. Мне пока в голову приходит только брать какие-то кадры и посчитать сумму разностей между пикселями на них.

                                                                                И есть ли где-то сравнительные таблицы кодеков, каким лучше сжимать, каким хуже?
                                                                                +1
                                                                                У вас лицензия в статьях в Википедии кривая. Почему вы передаёте в PD кадры из cc-by-sa произведения?

                                                                                Во-первых, вам не следует писать «собственная работа», а следует писать «производное от title, copyright by someone, original license cc-by-sa»
                                                                                Во-вторых, саму лицензию следует выбрать из семейства cc.
                                                                                  0
                                                                                  Пусть с этим разбираются патрулирующие википедию, они лицензии лучше знают. Мне они претензии не предъявляли, хотя статья проверена.
                                                                                    +1
                                                                                    Неправильный подход. «Пускай с этим разбирается редактор и корректор» — это можно сказать в обычном издании. В Википедии с большой вероятностью просто удалят вашу картинку из-за нарушений cc-by-sa лицензии оригинала. То есть сначала там повесят табличку о несоответствии лицензии, напишут вам, а потом удалят.

                                                                                    Кстати, в самой статье у вас стиль довольно сильно хромает.
                                                                                  0
                                                                                  в этой серии было бы ещё уместно рассказать о структуре самих потоков, форматов контейнеров,
                                                                                  принципиальных различиях ts/ps, с выбором которых всем приходится сталкиваться в первую очередь.
                                                                                    0
                                                                                    Очень интересно. Пожалуйста, пожалуйста: продолжение!
                                                                                      0
                                                                                      RGB -> YUV

                                                                                      Теперь понятно почему черно-белое (монохромное) видео при кодировании не занимает меньше места.
                                                                                        +1
                                                                                        На передачу цвета обычно тратится не более 20% от общего потока, так-то))
                                                                                        0
                                                                                        Не могу понять почему этот пост от января на главной странице в марте
                                                                                          0
                                                                                          Мы сделали виджет LiteVideo на NodeJs позволяющий работать с нашим оптимизатором видео
                                                                                          если интересно посмотреть можно тут
                                                                                          litevideo.7rtv.com/

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

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