Как исправить неверные расчеты меток времени? [OpenRtspClient] - PullRequest
3 голосов
/ 16 декабря 2011

Мои RTSP Source RTCP SR не надежны для некоторых из расчетных временных отметок потоков H.264, часто приводящих к большим отрицательным скачкам.

Вот пример из журнала отладки. Посмотрите, как он прыгает с 101006.6130 до -4193861.6830 и продолжает этот путь.

101619 : 5cd3c38 Sample 63682 bytes time 100605.6130 to 100605.6131 latency 1264447034.4738
101715 : 5cd3c38 Sample 74194 bytes time 100706.6130 to 100706.6131 latency 1264447039.4738
101815 : 5cd3c38 Sample 72484 bytes time 100804.6130 to 100804.6131 latency 1264447038.4738
101923 : 5cd3c38 Sample 95679 bytes time 100906.6130 to 100906.6131 latency 1264447031.4738
102023 : 5cd3c38 Sample 93004 bytes time 101006.6130 to 101006.6131 latency 1264447031.4738
102134 : 5cd3c38 Sample 91388 bytes time -4193861.6830 to -4193861.6829 latency 1260152052.1778
102222 : 5cd3c38 Sample 90912 bytes time -4193738.1730 to -4193738.1729 latency 1260152088.6878
102328 : 5cd3c38 Sample 105902 bytes time -4193636.1730 to -4193636.1729 latency 1260152083.6878
102430 : 5cd3c38 Sample 106334 bytes time -4193537.1730 to -4193537.1729 latency 1260152081.6878
102520 : 5cd3c38 Sample 107120 bytes time -4193437.1730 to -4193437.1729 latency 1260152090.6878

Итак, мой вопрос:

Как я могу решить эту проблему, используя Live555 media lib? Нужно ли мне игнорировать RTCP информация или что такое рекомендуемое решение и как я могу применять в Live555?

Ответы [ 2 ]

2 голосов
/ 19 декабря 2011

Вы используете live555 исключительно на клиенте?С неизмененным исходным кодом?Откуда берется информация о регистрации в вашем вопросе?

Как правило, всегда будет один скачок в отметке времени довольно близко к началу потока: это происходит, когда первый RTCP SRполученный клиентом, в этот момент клиент сбрасывает метку времени.Это необходимо для того, чтобы клиент мог синхронизировать несколько потоков, поскольку метки времени RTP как в аудио, так и в видео начинаются со случайного смещения.RTCP SR содержит отображение из метки времени RTP в NTP, что позволяет клиенту синхронизировать метки времени.Тот факт, что временная метка переходит отрицательно, не имеет значения, поскольку обе метки времени RTP и NTP не подписаны.

Live555 заботится об этой синхронизации, и поэтому вы можете увидеть скачок временной метки довольно близко к началу.У вас есть возможность либо игнорировать все выборки, полученные до синхронизации RTCP, либо вы можете выполнить более сложное отображение смещения на ноль как до синхронизации RTCP, так и после.Вы можете проверить, произошла ли синхронизация, вызвав метод live555 RtpSource::hasBeenSynchronizedUsingRTCP().

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

1 голос
/ 26 декабря 2011

Я действительно не знаю реализацию RTCP SR;следовательно, я не знаю единиц, которые 100605.xxxx представляет.Однако, если я предполагаю, что, как правило, если я считаю, что они получены из значений PTS / DTS тактового значения 90 кГц потока.

Если это правда, хорошо известно, что такие таймеры синхронизируются с частотой 2 ^ 33 бит.Это называется WRAPAROUND часов.Если это напечатано как подписанное число - это станет положительным.Такое свертывание произойдет ровно после определенного значения Clock.

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

Другая такая возможность называется непрерывность , которая возникает, когда временная база источника внезапно смещается (возможно, из-за некоторой неисправности).

...