Алгоритм сжатия видеоданных сообщение

Обновлено: 30.06.2024

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

PLV,
Compact Video,
Indeo, RTV
AVC,

но только Motion JPEG (Joint Photographic Experts Group), MPEG-1 и MPEG-2 . признаны международными стандартами для сжатия видео

Методы компрессии видео изображения.

MotionJPEG предcтавляет видео как последовательность JPEG кадров. MotionJPEG один из основных стандартов, используемых в сетевых видео системах. Сетевая видеокамера, подобно цифровому фотоаппарату, обрабатывает отдельные изображения, сжимая их в формат JPEG. Сетевая камера может обрабатывать несколько кадров в течении одной секунды (Axis 221 до 60 кадров в секунду), а затем, создав непрерывный поток, транслировать их в сеть. При скорости 16 кдр/сек и выше, человеческий глаз воспринимает поток образов как непрерывное видео. Поскольку MotionJPEG представляет собой поток отдельных JPEG картинок, его можно сравнить с кинопленкой - каждый кадр имеет четкое изображение, качество которого определяется только уровнем сжатия, выбранным для отдельной сетевой видеокамеры или видео сервера.
H.263 – формат сжатия предназначенный для передачи видео с постоянной, фиксированной скоростью. Основным недостатком фиксированной скорости является то, что при движении объекта качество изображения падает. H.263 был разработан для видео конференц-связи, а не для наблюдения, где отображение деталей являются более критичным, чем скорость передачи данных.
MPEG Основы разработки стандарта MPEG были заложены группой ученых из MPEG (Motion Picture Experts Group) еще в 80х годах прошлого века. Основной принцип MPEG сжатия это сравнение двух последовательных образов и передача по сети только небольшого количества кадров (так называемые I-frame или ключевые кадры), содержащих полную информацию об изображении. Остальные кадры (промежуточные кадры, P-frame) содержат только отличия этого кадра от предыдущего. Иногда применяют двунаправленные кадры (B-frame), информация в которых кодируется на основании предыдущего и последующего кадров, что позволяет дополнительно повысить степень сжатия видео. Во всех форматах MPEG используетсят метод компенсации движения.
Несмотря на большую сложность при кодировании/декодировании видео сигнала, MPEG сжатие позволяет значительно снизить (в разы) объемы передаваемой по сети информации по сравнению с MotionJPEG.
Основа кодирования у группы алгоритмов MPEG общая. Основные идеи, применяемые в ходе сжатия видеоданных с ее помощью, следующие:

- устранение временной избыточности видео, учитывающее тот факт, что в пределах коротких интервалов времени большинство фрагментов сцены оказываются неподвижными или незначительно смещаются по полю.
- устранение пространственной избыточности изображений путем подавления мелких деталей сцены, несущественных для визуального восприятия человеком.
- использование более низкого цветового разрешения при yuv-предеставлении изображений (y — яркость, u и v — цветоразностные сигналы) — установлено, что глаз менее чувствителен к пространственным изменениям оттенков цвета по сравнению с изменениями яркости.
- повышение информационной плотности результирующего цифрового потока путем выбора оптимального математического кода для его описания (например, использование более коротких кодовых слов для наиболее часто повторяемых значений).
На данный момент существует три стандарта MPEG для передачи видео информации.

Перспективные технологии - Advanced Video Coding (Расширенное кодирование видео данных)
В последнее время, описанные выше форматы сжатия H.263 и MPEG, начинают объединять, беря из них самое лучшее и передовое, для создания нового стандарта сжатия видео следующего поколения. Ожидается, что в течении ближайших нескольких лет, появится новый, более прогрессивный, стандарт сжатия потокового видео, который заменит используемые в настоящее время H.263 и MPEG-4.

Выводы В большинстве приложений используется формат сжатия Motion-JPEG, позволяющий найти компромисс между качеством и скоростью передачи видео изображения. MPEG-4 позволяет экономить дисковое пространство и менее требователен к размеру полосы пропускания, но предъявляет повышенные требования к ресурсам рабочей станции, обрабатывающей видео поток. В случаях, когда нужно только записывать или просматривать видео, MPEG-4 идеальный выбор, но если необходимо анализировать изображение предпочтение стоит отдать Motion-JPEG.

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

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

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

Формат пикселя. Пиксель не дает нам никакой информации кроме его цвета. Однако восприятие цвета сильно субъективно и были приложены большие усилия для создания систем цветопредставления и цветопередачи, которые были бы приемлемы для большинства людей. Так цвет, видимый нами в реальном мире, является достаточно сложным по спектру частот света, что передать его в цифровом виде крайне сложно, а отобразить еще сложней. Однако было замечено, что все тремя точками в спектре можно достаточно точно приблизить отображаемый цвет к настоящему в метрике восприятия цвета обычным человеком. Эти три точки: красный, зеленый и синий. То есть их линейной комбинацией мы можем покрыть большую часть видимого спектра цветов. Поэтому самый простой способ представления пикселя: 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) учитываются вектора движения, и создается изображение в целом похожее на исходный кадр.

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

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

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

В этом посте мы используем H.264 в качестве архетипического стандарта сжатия. Хотя это больше не новейший формат сжатия видео, он все же предоставляет достаточно подробный пример для объяснения общих понятий о сжатии видео.

Что такое сжатие видео?

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

I-кадры, P-кадры и B-кадры

I-кадры - это полностью закодированные изображения. Каждый I-кадр содержит все данные, необходимые для представления изображения. P-кадры основаны на том, как изображение переключается с последнего I-кадра. B-кадры направленно предсказаны, используя данные из обоего последнего P-кадра и следующего I-кадра. P-кадры должны хранить только визуальную информацию, которая является уникальной для P-кадра. В приведенном выше примере можно отследить, как точки перемещаются по всему кадру, но Pac-Man может оставаться там, где он есть.

Внутрикадровое кодирование (I-кадры)

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

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

В кодеках, которые используют прогнозирующие кадры, такие как H.264, I-кадры периодически обновляют поток данных путем установки нового опорного кадра. Чем дальше разнесены I-кадры, тем меньше может быть видеофайл. Однако, если I-кадры находятся слишком далеко друг от друга, точность прогнозирующих кадров видео будет постепенно ухудшаться до неразборчивости. Приложение с оптимизированной пропускной способностью будет вставлять I-кадры как можно реже, не прерывая видеопоток. Для потребителей частота I-кадров часто определяется косвенно настройкой качества в программном обеспечении кодирования. Профессиональное программное обеспечение для сжатия видео, такое как ffmpeg, позволяет осуществлять явный контроль.

Межкадровое прогнозирование (P-кадры и B-кадры)

Видеокодеры пытаются предсказать переход от одного кадра к другому. Чем ближе их прогнозы, тем эффективнее алгоритм сжатия. Это то, что создает P-кадры и B-кадры. Точное количество, частота и порядок прогнозирующих кадров, а также конкретный алгоритм, используемый для их кодирования и воспроизведения, определяются конкретным алгоритмом, который вы используете.

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

Вывод: сжатие данных

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

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

Введение

Основной сложностью при работе с видео являются большие объемы дискового пространства, необходимого для хранения даже небольших фрагментов. Причем даже применение современных алгоритмов сжатия не изменяет ситуацию кардинально. При записи на один компакт-диск "в бытовом качестве", на него можно поместить несколько тысяч фотографий, примерно 10 часов музыки и всего полчаса видео. Видео "телевизионного" формата 720х576 пикселов 25 кадров в секунду в системе RGB требует потока данных примерно в 240 Мбит/сек (т.е. 1.8 Гб в минуту). При этом традиционные алгоритмы сжатия изображений, ориентированные на отдельные кадры , не спасают ситуации, поскольку даже при уменьшении потока в 10 раз он составляет достаточно большие величины.

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

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

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

Основные понятия

Определимся с основными понятиями, которые используются при сжатии видео. Видеопоток характеризуется разрешением, частотой кадров и системой представления цветов. Из телевизионных стандартов пришли разрешения в 720х576 и 640х480, и частоты в 25 (стандарты PAL или SECAM ) и 30 (стандарт NTSC ) кадров в секунду. Для низких разрешений существуют специальные названия CIF - Common Interchange Format, равный 352х288 и QCIF - Quartered Common Interchange Format, равный 176х144. Поскольку CIF и QCIF ориентированы на крайне небольшие потоки, то с ними работают на частотах от 5 до 30 кадров в секунду.

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

Для алгоритмов сжатия видео характерны большинство тех же требований приложений, которые предъявляются к алгоритмам сжатия графики, однако есть и определенная специфика:

Произвольный доступ - подразумевает возможность найти и показать любой кадр за ограниченное время. Обеспечивается наличием в потоке данных так называемых точек входа - кадров , сжатых независимо (т.е. как обычное статическое изображение). Приемлемым временем поиска произвольного кадра считается 1/2 секунды.
Быстрый поиск вперед/назад - подразумевает быстрый показ кадров , не следующих друг за другом в исходном потоке. Требует наличия дополнительной информации в потоке. Эта возможность активно используется всевозможными проигрывателями.
Показ кадров фильма в обратном направлении. Редко требуется в приложениях. При жестких ограничениях на время показа очередного кадра выполнение этого требования может резко уменьшить степень сжатия.
Аудио-визуальная синхронизация - самое серьезное требование. Данные, необходимые для того, чтобы добиться синхронности аудио и видео дорожек, существенно увеличивают размер фильма. Для видеосистемы это означает, что, если мы не успеваем достать и показать в нужный момент времени некий кадр , то мы должны уметь корректно показать, например, кадр , следующий за ним. Если мы показываем фильм без звука, то можно позволить себе чуть более медленный или более быстрый показ. Во времена сравнительно несовершенного немого кино кадры шли настолько неравномерно, насколько неравномерно крутил ручку камеры оператор. Показ без звука фильма, снятого столь несовершенными методами, воспринимается нормально даже при условии, что частота показываемых кадров постоянна (и герои фильма то передвигаются карикатурно быстро, то медленно). Однако смотреть фильм (например, боевик), в котором видеосистема не успевает за звуком - становится мучением.
Устойчивость к ошибкам - требование, обусловленное тем, что большинство каналов связи ненадежны. Испорченное помехой изображение должно быстро восстанавливаться. Требование достаточно легко удовлетворяется необходимым числом независимых кадров в потоке. При этом также уменьшается степень сжатия, так как на экране 2-3 секунды (50-75 кадров ) может быть одно и то же изображение, но мы будем вынуждены нагружать поток независимыми кадрами.
Время кодирования/декодирования. Во многих системах (например, видеотелефонах) общая задержка на кодирование-передачу- декодирование должна составлять не более 150 мс. Кроме того, в приложениях, где необходимо редактирование, нормальная интерактивная работа невозможна, если время реакции системы составляет более 1 секунды.
Редактируемость. Под редактируемостью понимается возможность изменять все кадры так же легко, как если бы они были записаны независимо.
Масштабируемость - простота реализации концепции "видео в окне". Мы должны уметь быстро изменять высоту и ширину изображения в пикселах. Масштабирование способно породить неприятные эффекты в алгоритмах основанных на ДКП (дискретном косинусном преобразовании). Корректно реализовать эту возможность для MPEG на данный момент можно, пожалуй, лишь при достаточно сложных аппаратных реализациях, только тогда алгоритмы масштабирования не будут существенно увеличивать время декодирования . Интересно, что масштабирование достаточно легко осуществляется в так называемых фрактальных алгоритмах. В них, даже при увеличении изображения в несколько раз, оно не распадается на квадраты , т.е. отсутствует эффект "зернистости". Если необходимо уменьшать изображение (что, хоть и редко, но бывает нужно), то с такой задачей хорошо справляются алгоритмы, основанные на wavelet преобразовании (см. описание JPEG -2000).
Небольшая стоимость аппаратной реализации. При разработке хотя бы приблизительно должна оцениваться и учитываться конечная стоимость. Если эта стоимость велика, то даже при использовании алгоритма в международных стандартах , производители будут предлагать свои, более конкурентоспособные, алгоритмы и решения. На практике это требование означает, что алгоритм должен реализовываться небольшим набором микросхем.

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

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

Читайте также: