Я смотрю на приложение, которое требует, чтобы обнаружить задержку в получении видеокадров, а затем предпринимает действия, если задержка обнаружена. Задержка получения видеокадров воспринимается как остановка видео в окне рендеринга. Действие - вставка кадра IMU между видео в реальном времени, так как произошла остановка видео. Ниже приведены трубопроводы:
Tx-Rx подключены в режиме ad-hoc, используя Wi-Fi без каких-либо устройств. Также передается только видео, аудио здесь не имеет значения.
Tx (устройство iMX6):
v4l2src fps-n=30 -> h264encode -> rtph264pay -> rtpbin -> udpsink(port=5000) ->
rtpbin.send_rtcp(port=5001) -> rtpbin.recv_rtcp(port=5002)
Rx (Ubuntu PC):
udpsrc(port=5000) -> rtpbin -> rtph264depay -> avdec_h264 -> rtpbin.recv_rtcp(port=5001) ->
rtpbin.send_rtcp(port=5002) -> custom IMU frame insertion plugin -> videosink
Теперь, согласно моему приложению, я намерен определить задержку в получении кадров на устройстве Rx. Задержка может быть вызвана рядом факторов, включая:
- скопление
- потеря пакета
- шум и т. Д.
Как только задержка обнаружена, я намерен вставить кадр IMU (единица измерения инерции) (пользовательская визуализация) между кадром видео в реальном времени. Например, если задерживается каждый третий кадр, видео будет выглядеть так:
V | V | I | V | V | I | V | V | I | V | .....
где V - полученный видеокадр, а I - кадр IMU, вставленный на Rx-устройство
Следовательно, в соответствии с требованиями моего приложения, чтобы достичь этого, я должен знать метку времени видеокадра, отправленного с Tx, и использовать эту метку времени с текущей меткой времени на устройстве Rx, чтобы получить задержку при передаче.
задержка кадра = текущее время в Rx - отметка времени кадра в Tx
Поскольку я работаю со скоростью 30 кадров в секунду, в идеале следует ожидать, что я получаю видеокадры на устройстве Rx каждые 33 мс. Учитывая ситуацию, связанную с его WiFi, и другими задержками, включая кодирование / декодирование, я понимаю, что эту точность в 33 мс трудно достичь, и для меня это прекрасно.
- Поскольку я использую RTP / RTCP, я изучил WebRTC, но он больше ориентирован на отправку SR / RR (сетевой статистики) только для части данных, отправляемых с Tx -> Rx. Я также попытался использовать функцию тайм-аута источника UDP, которая определяет, нет ли пакетов в источнике в течение предварительно определенного времени, и выдает сигнал, уведомляющий об истечении времени ожидания. Однако это работает, только если устройство Tx полностью останавливается (конвейер останавливается с помощью Ctrl + C). Если пакеты задерживаются, время ожидания не наступает, поскольку ядро буферизует некоторые старые данные.
У меня есть следующие вопросы:
Имеет ли смысл использовать временные метки каждого видеокадра / буферов RTP для обнаружения задержки в приеме кадров на устройстве Rx? Какой дизайн лучше рассмотреть для такого варианта использования? Или это слишком большие издержки, чтобы учитывать временную метку каждого кадра / буфера, и, может быть, я могу рассмотреть временные метки фактора видеокадров, таких как каждый 5-й видеокадр / буфер или каждые 10 кадров / буфер? Кроме того, пакеты RTP не совпадают с FPS, что означает, что для видео со скоростью 30 кадров в секунду я могу получить более 30 буферов RTP в GStreamer. Учитывая наихудший случай, когда каждый альтернативный кадр задерживается, видео будет иметь следующую последовательность:
V | I | V| I | V | I | V | I | V | I | .....
Я понимаю, что точность каждого альтернативного кадра может быть затруднена, поэтому я нацеливаюсь на обнаружение и вставку кадра IMU по крайней мере в течение 66 мс. Также вызывает беспокойство переключение между живым видеокадром и вставляемым кадром. Я использую плагины OpenGL для обработки данных IMU.
Какие временные метки мне следует учитывать на устройстве Rx? Чтобы рассчитать задержку, мне нужен общий эталон между устройством Tx и Rx, о котором я не знаю. Я мог получить доступ к PTS и DTS буферов RTP, но так как никакой ссылки не было, я не мог использовать это, чтобы обнаружить задержку. Есть ли другой способ, которым я мог бы сделать это?
Мои шапки имеют следующие параметры (показаны только несколько параметров):
caps = application/x-rtp , clock-rate = 90000, timestamp-offset = 2392035930,seqnum-offset= 23406
Может ли это быть использовано для расчета эталона в Tx и Rx? Я не уверен, понимаю ли я эти цифры и как использовать их на устройстве Rx для получения справки. Любые указатели на понимание этих параметров?
- Любые другие возможные подходы, которые могут быть предприняты для такого применения. Моя вышеупомянутая идея может быть слишком непрактичной, и я открыт для предложений по решению этой проблемы.