Объединение RTP-пакетов

Question

У меня есть куча RTP-пакетов, которые я хотел бы собрать в аудиопоток.Для каждого пакета у меня есть порядковый номер, SSRC, временная метка и байтовый массив, представляющий сами данные.

В настоящее время я беру каждое подмножество пакетов по их SSRC, затем упорядочиваю их по меткам времени и объединяю байтовые массивы в этом порядке.После этого я смешиваю байтовые массивы.Полученные аудиоданные звучат великолепно (я имею в виду, что все вовремя), но я беспокоюсь, что это из-за небольшой потери пакетов.

Итак, пара вопросов ...

1. Для пропущенных пакетов пропущенный порядковый номер показывает, где мне нужно добавить немного пустого аудио.Я считаю, что порядковый номер довольно часто «оборачивается», поэтому мне нужно использовать метку времени, чтобы разбить их на подмножества.Затем я могу искать недостающие порядковые номера в этих подмножествах и добавлять по мере необходимости.Похоже, это правильно?

2. Я не совсем понял, для чего еще нужна временная метка.Поскольку я записываю уже существующие пакеты и заполняю пропущенные, может быть, мне не нужно об этом беспокоиться?

Answer 1

1) Избегайте использования временных меток в вашем алгоритме. Ваш алгоритм потерпит неудачу в случае, если вы получаете поток от плохих клиентов (неправильные метки времени). И значение «приращения временных меток» изменяется с типами кодеков. В этом случае вам могут понадобиться разные подмножества для разных кодеков. Нет ограничений на порядковый номер. Порядковый номер увеличивается монотонно. Используя порядковый номер, вы можете легко отслеживать потерянные пакеты.

2) Метка времени используется для синхронизации между аудио и видео. В основном для синхронизации губ. Для достижения синхронизации устанавливается связь между аудио и видео временными метками. В вашем случае это только аудио, так что вы можете избежать использования метки времени.

Редактировать: в соответствии с RFC 3389 (полезная нагрузка транспортного протокола реального времени (RTP) для комфортного шума (CN))

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

Answer 2

1) Я не думаю, что порядковый номер быстро «оборачивается». Это 16-битное значение, поэтому оно переносит каждые 65536 сообщений, и даже если сообщение отправляется каждые 10 миллисекунд, это дает более 10 минут передачи. Маловероятно, что пакет будет потерян так долго. Так что, на мой взгляд, вы должны проверять только порядковый номер, проверка отметки времени не имеет смысла.

2) Думаю, вам не стоит сильно беспокоиться о отметке времени. Я знаю, что некоторые протоколы даже не заполняют это значение и передают только по порядковому номеру.

Answer 3

Я думаю, что Зулин понял в своем ответе выше, что если ваши пакеты хранятся в том порядке, в котором они были захвачены, то вы можете использовать некоторые простые правила для поиска неупорядоченных пакетов - например, оглянуться назад на 50 пакетов и переслать 50 пакетов. Если его там нет, он считается потерянным пакетом.

Это должно избежать любых проблем, связанных с порядковым номером. Для обработки любых потерянных пакетов есть много методов, которые вы можете использовать, поэтому было бы полезно использовать Google «Потеря аудиопакета» или «Сокрытие потери VOIP-пакета». Как упоминает Адам, временная метка будет меняться в зависимости от кодека, поэтому вы должны понимать это, если собираетесь ее использовать.

Вы не упоминаете, что такое настоящее приложение, но если вы пытаетесь понять, как на самом деле звучит полученный звук, вам действительно нужно больше информации, в частности размер буфера дрожания - это эффективно определяет, как долго будет работать приемник. дождитесь несоответствующего пакета, прежде чем решить, что он потерян. Для вас это означает, что в вашем файле могут присутствовать пакеты вне последовательности, которые получатель «реального мира» отдал бы и не воспроизвел - т.е. ваша реконструкция из файла может дать более высокое качество, чем «реальная». опыт времени.

Если это двусторонняя передача, то задержка также очень важна (даже если это постоянная задержка и, следовательно, она не влияет на дрожание и потерю пакетов). Это тип эффекта, который вы использовали для некоторых радиотелефонов, и которые все еще действуют на некоторых спутниковых телефонах (или телефонах VoIP), и он может значительно повлиять на пользовательский опыт.

Наконец, разные кодеки и клиенты могут применять разные методы для исправления потерянных пакетов, вставки «бесшумных тонов» для любых пропусков в аудио (например, паузы в разговоре), подавления фонового шума и т. Д.

Чтобы получить представление о пользовательском опыте, вы должны попытаться как можно точнее «воспроизвести» ваши захваченные пакеты, используя тот же кодек, буфер дрожания и любые методы исправления ошибок / потери пакетов, используемые приемником.