Изучал этот вопрос около часа для случая звука.Похоже, ответ таков: временная метка RTP увеличивается на количество звуковых единиц времени (выборок) в пакете.Возьмите этот пример, где у вас есть поток закодированного 2-канального звука, сэмплированного на 44100 перед кодированием звука.Скажем, вы отправляете 512 аудиосэмплов (256 единиц времени, потому что у нас есть 2-канальный звук) для каждого пакета.Предполагая, что первый пакет имеет временную метку 0 (он должен быть случайным, хотя в соответствии со спецификацией RTP (RFC 3550)), вторая временная метка будет 256, а третья 512. Получатель может преобразовать значение обратно в фактическое время с помощьюделение метки времени на частоту дискретизации звука, поэтому первый пакет будет иметь значение T0, второй будет равен 256/44100 = 0,0058 секунды, третий - 512/44100 = 0,0116 секунды и т. д.
Кто-то, пожалуйста, исправьте меня, еслиЯ ошибаюсь, я не уверен, почему нет онлайн-статей, в которых так говорится.Я предполагаю, что было бы сложнее, если бы разрешение метки времени RTP отличалось от частоты дискретизации аудиопотока.Тем не менее, преобразование временной метки в другое разрешение несложно.Используйте пример, как и раньше, но измените разрешение временной метки RTP на 90 кГц, как в MPEG4 Audio (RFC 3016).Со стороны источника первая временная метка равна 0, вторая - 90000 * (256/44100) = 522, а третья - 1044. А на приемнике время равно 0 для первого пакета, 522/90000 = 0,0058 для второгои 1044/90000 = 0,0116 для третьего.Снова, кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь.