Полноцветное (24 бита на точку) изображение размером 720х576 пикселов из расчета 25 кадров в секунду требует потока данных примерно в 240 Мбит/с. С учетом того, что пропускная способность FDDI - примерно 100-200 Мбит/с, а Ethernet - всего 10 Мбит/с, такой поток данных слишком велик. Урезание изображения по ширине, высоте и времени в два раза даст выигрыш всего в 8 раз при заметной потере качества. Необходимо применение каких-то достаточно эффективных алгоритмов сжатия. Традиционные алгоритмы сжатия данных без потерь здесь практически не применимы, поскольку дают для реального видео слишком небольшой выигрыш. Например, алгоритмы, основанные на компрессии за счет одинаковых цепочек символов (LZ, LZW и т. п., использующиеся во многих универсальных архиваторах), не дают эффекта, так как на одном кадре реального видео такие цепочки встречаются редко.

Неплохим решением может оказаться использование алгоритмов компрессии статической графики - сжатия с потерями. При этом восстановленное изображение может не совпадать с исходным. Такие алгоритмы достаточно сложны и медленны. Видео же накладывает специфическое требование - декодер (программа-декомпрессор) должен успевать разархивировать изображение за 1/25 секунды, пока на экране предыдущий кадр. Данное ограничение не дает возможности реализовать интересные алгоритмы с большей степенью сжатия. Еще одно ограничение - сложность аппаратной реализации, поскольку в реальных приложениях (цифровые видеокамеры, видеотелефоны - видеофоны) часто оптимальным решением проблемы оказывается реализация алгоритма на заказном наборе микросхем, где мы, в свою очередь, ограничены числом транзисторов в чипе.

Развитие алгоритма

С середины 80-х многие западные университеты и лаборатории фирм работали над созданием алгоритма компрессии оцифрованного видео. Появилось достаточно большое число внутрифирменных стандартов. Область эта специфична - работы подталкиваются очень жесткими текущими требованиями, и международные стандарты появляются буквально через 2-3 года после создания алгоритма. Рассмотрим существующие стандарты в области цифрового видео.

В 1988 году в рамках Международной Организации по Стандартизации (ISO) начала работу группа MPEG - группа экспертов в области цифрового видео (ISO-IEC/JTC1/SC2/WG11/MPEG). Группа работает в направлениях, которые можно условно назвать MPEG-Video - сжатие видеосигнала в поток до 1,5 Мбит/с, MPEG-Audio - сжатие звука до 64, 128 или 192 Кбит/с на канал и MPEG-System - синхронизация потоков видео и аудио [1]. Нас в основном будут интересовать достижения MPEG-Video, хотя очевидно, что многие решения в этом направлении принимались с учетом требований синхронизации. Если быть более точным, то MPEG, как и другие стандарты на сжатие, описывает лишь выходной битовый поток, неявно задавая алгоритмы кодирования и декодирования. При этом их реализация перекладывается на разработчика программ, что открывает широкие горизонты для тех, кто желает оптимально реализовать алгоритм на конкретной платформе [2]. При таких реализациях могут быть учтены весьма специфические требования на время работы и расход памяти. В сентябре 1990 года был представлен предварительный стандарт кодирования MPEG-I. В январе 1992 года работа над MPEG-I была завершена. Сейчас группой ведутся работы над MPEG-II, в задачу которого входит определение потока данных от 3 до 10 Мбит/сек [3] (идет ориентация на двух скоростные CD-ROM).

Близкие стандарты

Работа эта была начата не на пустом месте, и, как алгоритм, MPEG имеет несколько предшественников. Это прежде всего JPEG [8] - универсальный алгоритм, разработанный группой экспертов в области фотографии Qoint Photographic Expert Group), предназначенный для сжатия статических полноцветных изображений. Его универсальность означает, что алгоритм дает неплохие результаты на широком классе изображений. Алгоритм использует конвейер из нескольких преобразований. Ключевым является дискретное косинусоидальное преобразование (ДКП), позволяющее в широких пределах менять степень сжатия без заметной потери качества изображения. Последняя фраза означает, что различить на глаз восстановленное и исходное изображения практически невозможно. Идея алгоритма состоит в том, что в реальных изображениях малы амплитуды высоких частот при разложении матрицы изображения в двойной ряд по косинусам. Можно достаточно свободно огрублять их представление, не сильно ухудшая изображение. Кроме того, используется перевод в другое цветовое проетранство (YUV), групповое кодирование, кодирование Хаффмана с постоянной таблицей.

Группой экспертов по видеотелефонам (EGVT) при Международном Консультационном Комитете по телефонной и телеграфной связи (CCITT) предложен стандарт видеотелефонов px64 Kbits [4,9]. Запись рх64 означает, что алгоритм ориентирован на параллельную передачу оцифрованного видеоизображения по р-каналам с пропускной способностью 64 Кбит/с; захватывая несколько телефонных линий, можно получать изображение вполне приемлемого качества. Одним из главных ограничений было время задержки, составляющее не более 150 мс. Кроме того, уровень помех в телефонных каналах достаточно высок, и это, естественно, нашло отражение в алгоритме. Можно считать, что px64 Kbits - предшественник MPEG для потоков данных менее 1,5 Мбит/с и специфического класса видео.

Работы группы при СМТТ (совместный комитет при CCITT и CCIR) были направлены на передачу оцифрованного видео по выделенным каналам с высокой пропускной способностью и радиолиниям. Соответствующие стандарты Н21 и Н22 ориентированы на 34 и 45 Мбит/с, и сигнал передается с очень высоким качеством.

Этапы разработки стандарта

В разработке MPEG, как и любого другого стандарта можно выделить следующие этапы:

1. Определение требований.
2. Разработка и сравнение различных решений.
3. Уточнение и окончательная доработка.

Определение требований

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

Носители информации, на которые ориентирован алгоритм:

1. CD-ROM - низкая стоимость при высокой плотности записи информации делают его наиболее привлекательным устройством, перспективным для хранения оцифрованного видео. Обладает рекордным отношением стоимости диска к его объему. Существенный недостаток - очень низкая скорость считывания информации (для односкоростных устройств - 1.5 Мбит/с), и большое время поиска информации (порядка 0.3 с).

2. DAT (Digital Audio Таре, стример) - достаточно большой размер и возможность записи информации компенсируются строго последовательным доступом (очень велико время поиска) и, опять же, небольшой скоростью считывания информации.

3. Жесткий диск (НЖМД) - наиболее быстрое и гибкое устройство, обладающее очень малым временем поиска, что необходимо для некоторых приложений. Однако он имеет очень высокое отношение стоимости диска к объему, что делает его существенно менее привлекательным.

4. Перезаписываемые оптические диски одно из наиболее перспективных устройств, способных сочетать в себе достоинства CD-ROM (низкая себестоимость хранения информации, большой объем, произвольный доступ) и жесткого диска (возможность перезаписи).

5. Компьютерные сети (как глобальные, так и локальные). Характеризуются возможностью быстро получать практически неограниченные объемы информации. Их быстрое развитие может способствовать появлению совершенно новых, неожиданных приложений для оцифрованного видео.

Можно выделить две группы приложений, использующих видео-компрессию - симметричные и несимметричные.

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

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

Требования к алгоритму

Следующие требования признаны необходимыми для алгоритма архивации оцифрованного видео:

Произвольный доступ - подразумевает возможность найти и показать любой кадр за ограниченное время. Обеспечивается наличием в потоке данных так называемых точек входа - кадров, сжатых независимо (т.е. как обычное изображение). Приемлемым временем поиска произвольного кадра считается 1/2 секунды.

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

Показ кадров фильма в обратном направлении. Редко требуется в приложениях. При жестких ограничениях на время показа очередного кадра выполнение этого требования может резко уменьшить степень архивации.

Аудио-визуальная синхронизация - самое серьезное требование. Данные, необходимые для того, чтобы добиться синхронности аудио и видео дорожек, существенно увеличивают размер фильма. Для видеосистемы это означает, что, если мы не успеваем достать и показать в нужный момент времени некий кадр, то мы должны уметь корректно показать, например, кадр, следующий за ним.

Устойчивость к ошибкам - требование, обусловленное ненадежностью большинства каналов связи. Испорченное помехой изображение должно быстро восстанавливаться. Это требование легко удовлетворить, включив в поток необходимое число независимых кадров. При этом теряется степень сжатия, так как на экране 2-3 секунды (50-75 кадров) может быть одно изображение, но мы будем вынуждены нагружать поток независимыми кадрами.

Время кодирования/декодирования. Во многих системах (например, видеотелефонах) общая задержка на кодирование-передачу-декодирование должна составлять не более 150 мс. Кроме того, в приложениях, где необходимо редактирование, нормальная интерактивная работа невозможна, если время реакции сосгавляет более 1 секунды.

Редактируемость. Под редактируемостью понимается возможность легко изменять все кадры так, как если бы они были записаны независимо.

Масштабируемость - легкость реализации концепции "видео в окне", позволяющия быстро измененять высоту и ширину изображения в пикселах. Масштабирование способно породить неприятные эффекты в алгоритмах основанных на ДКП (дискретном косинусоидальном преобразовании). Корректно реализовать эту возможность для MPEG на данный момент можно, пожалуй, лишь при достаточно сложных аппаратных реализациях, в которых алгоритмы масштабирования не будут существенно увеличивать время декодирования. Интересно, что это преобразование достаточно легко осуществляется в так называемых фрактальных алгоритмах. В них, даже при увеличении изображения в несколько раз, оно не распадается на квадраты (нет эффекта зернистости).

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

Алгоритм компрессии

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

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

Уменьшение избыточности во временном измерении

Чтобы удовлетворить противоречивые требования и увеличить гибкость алгоритма, выделяются четыре типа кадров:

  • I-кадры - независимо сжатые (I-Intrapictures),
  • Р-кадры - сжатые с использованием ссылки на одно изображение (P-Predicted),
  • В-кадры - сжатые с использованием ссылки на два изображения (В-Bidirection),
  • ВС-кадры - независимо сжатые с большой потерей качества (используются только при быстром поиске).

I-кадры обеспечивают возможность произвольного доступа к любому кадру, являясь своеобразными входными точками в поток данных для декодера. Р-кадры используют при архивации ссылку на один I- или Р-кадр, повышая тем самым степень сжатия фильма в целом. В-кадры, используя ссылки на два кадра, находящихся впереди и позади, обеспечивают наивысшую степень сжатия. Сами в качестве ссылки использоваться не могут.

Последовательность кадров в фильме может быть, например, такой: IBBPBBPBBPBBIBBPBB... Частота I-кадров выбирается в зависимости от требований на время произвольного доступа. Соотношение Р - и В-кадров подбирается, исходя из требований к величине компрессии и ограничений декодера. Именно варьирование частоты кадров разных типов обеспечивает алгоритму необходимую гибкость и возможность расширения. Понятно, что для того, чтобы распаковывать В-кадр, мы должны уже распаковать те кадры, на которые он ссылается, поэтому для приведенного выше примера последовательность кадров на диске будет такой: 0**312645..., где цифры - номера кадров, а звездочкам соответствуют либо В-кадры с номерами - 1 и - 2, (в середине потока), либо пустые кадры (в начале фильма). Подобный формат обладает достаточно большой гибкостью и способен удовлетворять самым различным наборам требований.

Одно из основных понятий при сжатии нескольких изображений - макроблок. Макроблок - это матрица пикселов 16х16 элементов (размер изображения должен быть кратен 16). Такая величина выбрана не случайно - ДКП работает с матрицами размером 8х8 элементов. При сжатии каждый макроблок из цветового пространства RGB переводится в цветовое пространство YUV. Матрица, соответствующая Y (яркостному компоненту) превращается в четыре исходных матрицы для ДКП, а матрицы, соответствующие компонентам U и V, прореживаются на все четные строки и столбцы, превращаясь в одну матрицу для ДКП. Таким образом, мы сразу получаем сжатие в два раза, пользуясь тем, что глаз человека хуже различает цвет отдельной точки изображения, чем ее яркость.

Отдельные макроблоки сжимаются независимо, т.е. в В-кадрах можно сжать макроблок как I-блок, Р-блок со ссылкой на предыдущий кадр, Р-блок со ссылкой на последующий кадр и, наконец, как В-блок.

Сжатие отдельных кадров

Общий обзор алгоритма

Существует достаточно много алгоритмов, сжимающих статические изображения. Для нас предпочтительными являются те, которые основаны на сжатии изображения небольшими блоками. Из них чаще всего используются алгоритмы на базе дискретного косинусоидального преобразования. Алгоритм сжатия отдельных кадров в MPEG похож на соответствующий алгоритм для статических изображений - JPEG.

Говоря коротко, сам алгоритм сжатия представляет собой конвейер преобразований. Это дискретное косинусоидальное преобразованиеисходной матрицы Sx8, квантование матрицы и вытягивание ее в вектор а11, а12, а21, а31, а22, ..., а88 (зигзаг-сканирование), сжатие вектора групповым кодированием и, наконец, сжатие по Хаффману.

Алгоритм сжатия изображений

Итак, к макроблокам, которые нам готовит алгоритм уменьшения избыточности во временном измерении, применяется ДКП. Само преобразование заключается в разложении значений дискретной функции двух переменных в двойной ряд по косинусам некоторых частот. Дискретное косинусоидальное преобразование переводит матрицу значений в диапазоне от -255 до 255 в матрицу амплитуд со значениями от -2047 до 2047. Смысл преобразования заключается в том, что амплитуды, соответствующие более низким частотам, записываются в левый верхний угол матрицы, а те, которые соответствуют более высоким - в правый нижний. Поскольку в реалистичных изображениях высокочастотная составляющая очень мала по амплитуде, в результирующей матрице значения под побочной диагональю либо близки, либо равны нулю. В настоящее время ДКП довольно хорошо исследовано. Известны алгоритмы быстрого целочисленного ДКП, которые, в частности, приводятся в [11].

В упрощенном виде это преобразование можно представить так:

К полученной матрице амплитуд применяется операция квантования. Это основная операция в конвейере. Именно на этапе квантования-группового кодирования в основном и происходит адаптивное сжатие; кроме того, именно на этом этапе происходят основные потери качества фильма. Квантование - это целочисленное поэлементное деление матрицы амплитуд на матрицу квантования (МК). Подбор значений МК позволяет увеличивать или уменьшать потери по определенным частотам, и регулировать качество изображения и степень сжатия. Заметим, что для различных компонентов изображения могут быть свои МК.

Квантование выглядит как

Следующий шаг алгоритма заключается в преобразовании полученной матрицы Sxs в вектор из 64 элементов. Этот этап называется зигзаг-сканированием, т.к. элементы из матрицы выбираются, начиная с левого верхнего, зигзагом по диагоналям, параллельным побочной диагонали. В результате получается вектор, в начальных элементах которого находятся элементы матрицы, соответствующие низким частотам, а в конце - высоким. Следовательно, в конце вектора будет очень много нулевых элементов.

Групповое кодирование в MPEG представляет собой перевод вектора, полученного после зигзаг-сканирования в пары (пропустить, значение), где первый элемент задает число пропускаемых нулей, а второй - значение, которое необходимо записать в следующую ячейку.

После группового кодирования полученные пары сжимаются алгоритмом сжатия по Хаффману с фиксированной таблицей.

Общая схема алгоритма

В целом конвейер преобразований можно представить так:

1) Подготовка макроблоков. Для каждого макроблока определяется, каким образом он будет сжат. В I-кадрах все макроблоки сжимаются независимо. В Р-кадрах блок либо сжимается независимо, либо представляет собой разность с макроблоком в предыдущем опорном кадре, на который ссылается Р-кадр.

2) Перевод макроблока в цветовое пространство YUV. Получение нужного количества матриц 8х8.

3) ДКП.

4) Квантование.

5) Зигзаг-сканирование.

6) Групповое кодирование.

7) Кодирование Хаффмана.

При декодировании конвейер прокручивается в противоположном направлении с выполнением обратных преобразований.

Возможности распараллеливания

Даже беглый взгляд на алгоритм позволяет заметить, что он сравнительно легко распараллеливается. Изображение 320х240 содержит 330 макроблоков, которые можно кодировать и декодировать независимо. Каждый макроблок, в свою очередь, содержит шесть блоков данных для ДКП. Распараллелить ДКП очень важно, поскольку это самая медленная операция во всем алгоритме. Заметим также, что остальные преобразования легко конвейеризуются. В результате мы получаем параллельно-конвейерную схему обработки потока видеоданных.

Достаточно заманчиво выглядит возможность распараллелить обработку различных кадров, но это связано с определенными сложностями. Как правило, программа архивации строится таким образом, чтобы сжатое изображение подвергалось обратным преобразованиям. Таким образом, мы получаем кадр с потерями и архивируем остальные кадры, отталкиваясь от него. Это позволяет не накапливать ошибки, получаемые еще при квантовании. Если на экране между кадрами наблюдались большие изменения, и качество изображения пришлось понизить, то при стабилизации изображения качество быстро повышается практически до качества исходного видеоряда. Неприятный эффект, порождаемый этим приемом, состоит в появлении мерцающих отдельных точек (или даже областей) изображения, значение цвета в которых округляется то в большую, то в меньшую сторону.

При разархивации возможности по параллельной обработке различных кадров достаточно ограничены, поскольку велика зависимость между кадрами в потоке (велик процент Р - и В-кадров).

Развитие MPEG-II

Сейчас группа MPEG занимается сжатием оцифрованного видео при потоке данных от 3 до 10 Мбит/с. В частности, ведутся работы, связанные с переводом из формата CCIR-6,01 в MPEG. CCIR-601 - это стандарт цифрового видео с размером передаваемого изображения 720х486 при 60 полукадрах в секунду. Строки изображения передаются с чередованием, и два полукадра составляют кадр. Этот прием нередко применяют для уменьшения мерцания. Хроматические каналы (U и V в YUV) передаются размером 360x243 60 раз в секунду и чередуются уже между собой. Подобное деление называется 4:2:2. Оно позволяет уменьшить избыточность в два раза только за счет перевода в другое цветовое пространство. Кстати, подобный прием давно используется в обычном телевидении, где на яркостную составляющую выделяется чуть более широкая полоса частот, что, с одной стороны, обеспечивает совместимость со старыми черно-белыми телевизорами, а с другой стороны повышает качество изображения. Перевод из CCIR-601 в MPEG-I прост - надо уменьшить вдвое число столбцов в яркостном компоненте, разделить на два поток во временном измерении (убрав чередование), добавить второй хроматический компонент и выкинуть "лишние" строки, чтобы размер по вертикали был кратен 16. Мы получим поток YUV кадров размером 352х240 с частотой 30 кадров в секунду. Здесь все просто.

Трудности начинаются, когда появляется возможность увеличить поток данных и довести качество изображения до CCIR-601. Это не такая простая задача, как кажется. Проблема состоит в чередовании полукадров во входном формате. Тривиальное решение - работать с кадрами 720х486 при 30 кадрах в секунду, как с обычным видео. Однако, этот путь ведет к появлению неприятных эффектов при быстром движении объектов на экране. Между двумя исходными полукадрами 720х243 сдвиг становится заметным, а так как кадр формируется из исходных полукадров через строку, то при сжатии происходит размывание движущегося объекта. Виновно в этом эффекте ДКП, и исправить ситуацию, не уменьшив коэффициента компрессии видео, нельзя.

Другим решением является архивация четных и нечетных кадров в потоке CCIR601 независимо. Это, конечно, позволяет избавиться от артефактов, возникающих при быстром движении объектов, но существенно уменьшает степень сжатия, поскольку не используется избыточность между соседними кадрами, которая очень велика.

Также можно пытаться интерполировать значения между соседними кадрами. На самом деле решений очень много. Так как MPEG-II развивается в общем самостоятельно, то, по-видимому, в него войдут какие-то из альтернативных подходов, которые были отброшены при принятии решения относительно MPEG-I.

Построение алгоритмов на базе MPEG

В последнее время изображения, создаваемые компьютером, становятся все более и более реалистичными. Программное (типа библиотеки OpenGL для Unix-станций) и аппаратное (платы, способные выводить сотни тысяч трехмерных треугольников в секунду) обеспечение позволяет создавать трехмерные фильмы в реальном масштабе времени. Один из наиболее распространенных приемов достижения реалистичности - использование текстур. Текстура - это изображение, "наклеиваемое" на поверхности граней объектов. Благодаря этой технологии появляется возможность нарисовать стол действительно деревянным, на стенах изобразить обои, а за окном - пейзаж (изображения, наклеенные на несколько поверхностей на разном расстоянии от окна, соответствующим образом освещенные). На базе подобных "виртуалънореалистичных" систем сейчас разрабатывается масса приложений - от систем поиска информации в базах данных и до компьютерных игр. Поскольку алгоритмы в этой области сложны и требуют существенной вычислительной мощности, а компьютерные сети достаточно развиты (по крайней мере, на Западе), то наиболее перспективным путем является передача по компьютерным сетям только изображения. Тогда в качестве конечных станций смогут выступать даже персональные компьютеры, от которых будет требоваться только умение быстро распаковать приходящий фильм. В этом, в определенном смысле, повторяется ситуация 70-х с интеллектуальными терминалами больших машин.

Итак, вопрос заключается в том, чтобы достаточно эффективно обеспечивать сжатие таких фильмов. Точнее - нельзя ли какнибудь использовать то, что мы сами строим отдельные кадры, и соответственно, обладаем некой дополнительной информацией. Кроме того, фильмы в системах виртуальной реальности относятся к специфическому классу изображений - в них, как правило, камера поворачивается относительно неподвижных объектов (так называемое панорамирование), либо "наезжает" на них. Из этого следует, что, во-первых, чистый MPEG не будет обеспечивать хороших показателей (изображение меняется от кадра к кадру практически по всему экрану), вовторых - большая часть нового кадра присутствует на старом, быть может со сдвигом, поворотом и растяжением.

Попробуем передавать двумерную матрицу сдвига каждого пиксела DX [i, j] и DY [i, j]. Тогда в случае "наезда" камерой на набор многогранников в матрицах DX и DY получаются области близких значений, резкие переходы в которых будут соответствовать ребрам видимых граней, находящимся на разных расстояниях от камеры. При преобразовании ДКП получаются буквально единичные ненулевые значения, что, в свою очередь, обеспечивает очень высокий коэффициент компрессии. При использовании MPEG можно формировать очередной псевдокадр как (R,G,B)[i,j]=(128+DX[i,j], 128+DY[i,j], 128). Таким образом, для некоторых специфических видов видео можно добиваться гораздо больших коэффициентов компрессии, несколько модифицируя MPEG-архивацию.

***

Бурное развитие мультимедиа, объединяющего в себе видео, звук, графику и гипертекст, порождает активные исследований в области сжатия оцифрованного видео. Появление и распространение CD-ROM, позволяющих хранить большие объемы информации, и их низкая цена (стоимость тиражирования информации на электронном носителе становится дешевле тиражирования на бумаге) сделали исследования в области цифрового видео очень актуальными. Описанный алгоритм позволяет успешно показывать оцифрованное видео с величиной битового потока порядка 1.2-1.8 Мбит/с, что позволяет использовать его при показе видео с CD-ROM, оптических дисков, жестких дисков, стримеров, и передавать в реальном времени по сетям.

Литература

1. Le Gall D.А. MPEG: а video compression standart for multimedia applications. Communication of АСМ. Volume 34. Number 4. April 1991.

2. D.S Wallach, S Kunapalli, M.F Cohen. Accelerated MPEG compression of Dynamic poligonal scenes АСМ Jun 1994.

3. FAQ-статья по MPEG. Ver 2.0-3.0. Мау 1993. PHADE SOFTWARE. Berlin.

4. Liou Ming. Overview of the рх64 kbit/s video coding standart. Communication of ACM. Vol 34. N.4 April 1991.

5. Anderson М. VCR quality video at 1,5 Mbit/s. National Communication Forum (Chicago, Oct. 1990).

6. Chen С.Т. and Le Gall D.А. А Kth order adaptive transform coding algorithm for high-fidelity econstnction of still images. In Proceedings of the SPIE (San Diego, Aug. 1989).

7. Coding of moving pictures and associated audio. Committee Draft of Standart ISO11172: ISO/MPEG 90/176 Dec. 1990.

8. JPEG digital compression and coding of continuus-tone still images. Draft ISO 10918. 1991.

9. Video codec for audio visual services at px64 kbit/s. CCITT Recommendation H.261 1990.

10. MPEG proposal package description. Document ISO/WG8/MPEG 89/128 (July 1989).

11. К.R Rao and Р. Yip Discrete Cosine Transform - Algorithms, Advantages, Applications. (Academic Press, London, 1990).