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