7.7. Декодирование, смешивание и проигрывание

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

7.7.1. Декодирование

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

Рис. 7.8. Декомпрессия фреймов декодером

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

7.7.2. Смешивание звука

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

Рис. 7.9. Смешивание звука

Глава 8. Синхронизация звука и изображения

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

Рис. 8.1. Синхронизация потоков мультимедиа

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

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

8.1. Поведение отправителя

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

Рис. 8.2. Выравнивание времени по общим часам

Соответствие между общим временем и потоковым определяется в момент формирования пакета RTCP. Общее время T_reference отражается в метке времени пакета RTP:

T_RTP = T_reference × R_audio + O_audio

Отсюда получаем смещение часов:

O_audio = T_audio – (T_available – D_{audio_capture}) × R_audio

Здесь T_available определяется задержками операционной системы, а D_{audio_capture} – длительностью процесса захвата данных.

На рис. 8.3 демонстрируется необходимость синхронизации часов, когда потоки мультимедиа получаются из разных источников.

Еще одна проблема синхронизации – идентификация потоков, к которым она должна быть применена. RTP решает ее путем выдачи связанным источникам общих имен (CNAME), поэтому получатель различает зависимые и независимые потоки.

Рис. 8.3. Синхронизация потоков от разных источников

8.2. Поведение получателя

Получатель должен выделить синхронизируемые потоки и выровнять их перед проигрыванием. Первое достигается достаточно просто использованием одинаковых имен CNAME в разных потоках. Сложнее сама процедура синхронизации (рис. 8.4 и 8.5).

Рис. 8.4. Синхронизация звука и изображения на стороне пользователя

Рис. 8.5. Установление соответствия времен на стороне пользователя

Получатель вначале определяет соответствие между общим временем, установленным отправителем, и временем синхронизируемых потоков путем сравнивания данных RTP и RTCP пакетов. При получении пакета данных RTP с меткой времени M может быть вычислено время захвата:

Здесь M_sr – метка времени RTP в последнем полученном пакете RTCP, T_Ssr – общее время в секундах, R – номинальная скорость часов данных в герцах. Получатель также вычисляет время вывода синхронизированных данных T_R согласно локальным часам. Оно равно метке времени пакета, согласованной с общим временем отправителя, плюс задержка в буфере проигрывания для декодирования, смешивания и обработки.

Когда время захвата и проигрывания известны, получатель может вычислить относительную задержку между захватом данных и их проигрыванием для каждого потока. Если данные захвачены во время T_S по общему времени отправителя и выводятся в момент времени T_R по часам получателя, то разница между ними D = T_R – T_S даст величину задержки между захватом изображения и его выводом. Из-за того, что часы отправителя и получателя не синхронизированы, это значение включает в себя неизвестное смещение между ними, но его можно игнорировать, так как оно одинаково для всех синхронизируемых потоков, а нас интересует только относительное смещение между потоками.

После вычисления этой задержки как для потока звука, так и для потока изображения можно вычислить собственно задержку синхронизации потоков D = D_audio – D_video. Если это значение получится равным нулю, то потоки синхронизированы. В противном случае оно дает смещение между потоками в секундах.

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

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

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