7.2.3. Использование предварительно записанной информации
Подготовленные фреймы обычно поступают на этап пакетизации в том же порядке, в каком они были захвачены. Протокол RTP не делает различий между предварительно записанной информацией и «живым» потоком.
В частности, в начале предварительно записанной информации отправитель должен сгенерировать новый идентификатор SSRC и выбрать случайные значения для метки времени и порядкового номера. В процессе передачи он должен управлять SSRC коллизиями, получать и отправлять пакеты RTCP.
Предположим, что отправитель не может просто брать поток из файла и помещать его содержимое тоже в файлы. Вместо этого он использует процесс запоминания и пакетизации «на лету» (рис.7.3).
Рис. 6.3. Использование предварительно записанной информации
7.3. Генерация пакетов rtp
Сгенерированные сжатые фреймы передаются процедуре пакетизации. Каждому фрейму соответствует метка времени, из которой получается метка времени RTP. Если формат данных поддерживает фрагментацию, большие фреймы разделяются на максимально допустимые для передачи фрагменты (обычно это необходимо только для видео). Наконец, один или несколько RTP пакетов, содержащих заголовок и собственно данные, генерируются для каждого фрейма. Формат пакета и его заголовка определяется используемым кодеком. Критической частью процесса генерации пакетов является назначение фреймам меток времени, фрагментирование больших фреймов и генерация заголовков данных. Эти моменты мы и обсудим более подробно.
7.3.1. Метки времени и модель времени rtp
Метка времени представляет момент получения первого байта данных. Значение начинается со случайно сгенерированного числа и возрастает со скоростью, определяемой передаваемыми данными.
В процессе захвата «живого» потока мультимедиа метка времени обозначает момент получения первых сэмплов с устройства захвата. Если речь идет о синхронизированных звуковых и видео потоках, то надо быть уверенным, что время обработки потоков разного типа учтено при вычислении метки времени. Для большинства звуковых форматов метка времени RTP для каждого очередного пакета возрастает пропорционально числу входящих в него сэмплов, а не байтов данных его длины. Исключением является форматы звука MPEG, включая формат MP3, который использует частоту 90 КГц в данных для совместимости с другими форматами MPEG. Большинство форматов видео также используют часы 90 КГц, что дает им возможность увеличивать значение метки времени целыми значениями шага. Например, при использовании стандартной для NTSC скорости 29.97 фреймов в секунду и использовании в данных частоты 90 КГц метка времени RTP будет увеличиваться на 3.003 на каждый пакет.
Для потока, предварительно записанного в файле, метка времени дает время фрейма в последовательности фреймов плюс постоянное случайное смещение. Метки времени назначаются для фреймов, поэтому, если большой фрейм фрагментируется, каждый фрагмент будет иметь одинаковую метку времени.
Спецификация RTP не гарантирует детальность, точность и стабильность часов данных. Каждое приложение само решает эту задачу.
Метка времени в RTP данных и отсылаемых отправителем RTCP пакетах отражает параметры времени у отправителя. Отметим, что модель времени RTP ничего не говорит о времени проигрывания передаваемых данных. Метки времени данных дают относительные параметры времени и RTCP отчеты отправителя помогают синхронизировать разные потоки. Но RTP ничего не говорит о количестве буферов, используемых для проигрывания данных или о времени их раскодирования.
Хотя модель времени детально описана в спецификации RTP, в ней нет упоминания об алгоритмах, используемых при реконструкции параметров времени на стороне получателей пакетов. Это сделано преднамеренно, так как такие алгоритмы зависят от требований самого приложения.