Теперь посмотрим, как работают алгоритмы MPEG (в упрощенном виде). Кадр, идущий следом за полным (базовым) кадром JPEG, здесь выглядит почти так же, как в случае алгоритма JPEG. Поэтому вместо того, чтобы кодировать полный кадр, передаются только блоки с отличиями от базового кадра. Блок с фрагментом голубого неба, скорее всего, будет выглядеть так же и через 20 мс, и нет смысла отправлять его снова. Повторно следует передавать только те блоки, в которых произошли изменения.
Рассмотрим пример, когда камера закреплена на штативе, а актер идет к неподвижным дереву и дому. Первые три кадра показаны на илл. 7.32. При кодировании второго кадра отправляются лишь те блоки, в которых произошли изменения. Теоретически, чтобы его принять, получателю нужно просто скопировать первый кадр в буфер, а затем применить изменения. После этого он сохраняет второй кадр в несжатом виде для отображения на экране. Он также использует второй кадр как основу для применения следующих изменений, отражающих различия между третьим и вторым кадром.
Илл. 7.32. Три последовательных кадра
В реальности этот процесс чуть сложнее. Если блок (например, с актером) присутствует во втором кадре, но с некоторым смещением, алгоритм MPEG позволяет кодировщику сообщить следующее: «Блок 29 предыдущего кадра присутствует в новом кадре со смещением на расстояние (∆x, ∆y), и кроме того, шестой пиксель теперь содержит значения abc, а 24-й пиксель — значения xyz». Это обеспечивает еще большее сжатие.
Ранее мы упоминали об асимметрии между кодированием и декодированием. Здесь мы видим еще один случай такой асимметрии. Кодировщик может сколько угодно искать смещенные и измененные блоки. Так он решает, что лучше: отправить список обновлений предыдущего кадра или новый полный кадр JPEG. При этом поиск смещенного блока требует гораздо больше усилий, чем его копирование из предыдущего кадра и вставка в новый кадр с известным смещением (∆x, ∆y).
На самом деле для полноты картины в MPEG используются не два, а три разных вида кадров:
1. I-кадры (Intracoded — закодированные внутри), которые содержат неподвижные изображения, сжатые независимо от других кадров.
2. P-кадры (Predictive — предиктивные); отражают отличия от предыдущего кадра.
3. B-кадры (Bidirectional — двунаправленные); отражают отличия от следующего I-кадра.
B-кадры требуют, чтобы получатель останавливал обработку до поступления следующего I-кадра, а затем возвращался назад. Иногда это обеспечивает большую степень сжатия, но когда кодировщик постоянно проверяет, что даст результат с наименьшим размером — отличия от предыдущего кадра или отличия от одного из следующих 30, 50 или 80 кадров, это ведет к большим затратам времени на стороне кодирования без больших затрат на стороне декодирования. Эта асимметрия используется по максимуму для того, чтобы обеспечить на выходе файл минимально возможного размера. Стандарты MPEG не определяют, как и на каком расстоянии должен производиться поиск и какой должна быть степень совпадения, чтобы передавать отличия или новый полный блок. Все зависит от конкретной реализации.
Аудио и видео кодируются по отдельности описанным выше способом. Окончательный результат MPEG-кодирования представляет собой файл, состоящий из ряда сегментов, которые содержат определенное число сжатых изображений и соответствующие им сжатые аудиоданные; они должны воспроизводиться при отображении кадров данного сегмента. Это позволяет избегать рассогласования видео- и аудиоданных.
Обратите внимание, что это несколько упрощенное описание. В реальности данный подход использует еще несколько способов повышения степени сжатия, но изложенные выше основные принципы при этом не меняются. Последняя версия данного формата — это MPEG-4 (MP4). Ее формальное описание представлено в стандарте H.264. Следующей версией H.264 (предназначенной для описания разрешений до 8K) является стандарт H.265. Формат H.264 используется большинством потребительских видеокамер. Поскольку камера должна записывать видео на SD-карту или другой носитель в режиме реального времени, у нее остается совсем немного времени на поиск слегка сместившихся блоков. Как следствие, степень сжатия при этом очень далека от того уровня, который может обеспечить голливудская киностудия, динамически выделив на облачном сервере 10 000 компьютеров для кодирования своего творения. Это еще один пример реального проявления асимметрии между кодированием и декодированием.
7.4.3. Потоковая передача сохраненных медиафайлов
Теперь перейдем к сетевым приложениям. В первую очередь следует обсудить просмотр потокового видео, которое уже хранится где-то на сервере, как в случае с YouTube или Netflix. Самый распространенный пример — онлайн-просмотр видео. Это одна из форм видео по запросу (Video on Demand, VoD). Другие формы VoD для передачи фильмов используют провайдерскую сеть, которая не является частью интернета (например, сеть кабельного телевидения).
В интернете очень много сайтов с музыкой и видео, предоставляющих потоковый доступ к хранящимся на них медиафайлам. По сути, самый простой способ обработки таких медиафайлов — не передавать их в потоковом режиме. Намного проще рассматривать предварительно закодированный видео- или аудиофайл как очень большую веб-страницу и позволить браузеру его скачать. Эта последовательность из четырех шагов показана на илл. 7.33.
Илл. 7.33. Воспроизведение медиафайлов по интернету путем обычного скачивания
Браузер начинает действовать, когда пользователь кликает по названию фильма. На первом шаге отсылается HTTP-запрос фильма на веб-сервер, на который указывает ссылка. На втором шаге сервер получает фильм (который представляет собой обычный файл в формате MP4 или каком-нибудь другом) и отправляет его браузеру. Исходя из MIME-типа файла, браузер выбирает способ воспроизведения. На третьем шаге браузер сохраняет весь фильм на диске во временном файле и запускает медиаплеер, которому передается имя временного файла. Наконец, на четвертом шаге медиаплеер начинает читать файл и проигрывать фильм. Теоретически это мало чем отличается от доставки и отображения статической веб-страницы, разница лишь в том, что загруженный файл «отображается» с помощью медиаплеера, а не просто путем записи пикселей в монитор.
В целом это вполне корректный подход, который позволит нормально воспроизвести файл с фильмом. У вас не будет никаких проблем с передачей данных по сети в режиме реального времени, поскольку в данном случае требуется лишь скачать файл. Правда, до начала воспроизведения необходимо передать по сети всю видеозапись. Большинство клиентов не хочет ждать целый час, пока начнется воспроизведение выбранного ими «видео по запросу», поэтому нужно найти решение получше.
На помощь приходит медиаплеер для потоковой передачи. Это может быть либо компонент веб-браузера, либо внешняя программа, вызываемая браузером, когда требуется воспроизвести видео. Современные браузеры с поддержкой HTML5 имеют встроенный медиаплеер.
Медиаплеер решает пять основных задач:
1. Управление интерфейсом пользователя.
2. Обработка ошибок передачи.
3. Декомпрессия сжатых данных.
4. Устранение джиттера.
5. Дешифрование файла.
Большинство современных медиаплееров обладает привлекательным интерфейсом, иногда имитирующим внешний вид стереосистемы с блестящими кнопками, ручками, ползунками и дисплеями. Зачастую пользователь может менять внешний вид плеера, выбирая разные «лицевые панели», скины (skins). Медиаплеер должен всем этим управлять, обеспечивая взаимодействие с пользователем.
Следующие три задачи связаны друг с другом и зависят от используемых сетевых протоколов. Рассмотрим их по очереди, начиная с обработки ошибок передачи. Ее сложность зависит от того, какой транспортный протокол используется для доставки медиаданных. Это может быть протокол, основанный на TCP (такой, как HTTP) или на UDP, например протокол реального времени (Real Time Protocol, RTP). При использовании транспортного протокола на основе TCP медиаплееру не придется исправлять ошибки, ведь TCP и так обеспечивает высокую надежность за счет повторной передачи. Это упрощает (по крайней мере, для медиаплеера) обработку ошибок, но в то же время усложняет удаление джиттера на более позднем этапе, поскольку тайм-ауты и повторная передача могут приводить к нестабильным и переменным задержкам при воспроизведении фильма.