Проблема
Я пытаюсь вычислить время, прошедшее в RTCPeerConnection между:
- Время (A): Узел A выполняет событие на веб-камера (например, снимки) ,
- Время (B): узел B просматривает событие из времени (A) (например, слышит щелчок узла A) и одновременно выполняет событие (например, привязка одновременно) и
- время (C): узел A просматривает событие, выполненное узлом B во время (B) (например, слышит узел B))
Вопрос
Как рассчитать время, прошедшее между временем (A) и временем (C) (для RTCPeerConnection в Javascript)?
Мое понимание проблемы
Мне не удалось найти хорошее описание всех мест в цепи, где время может пройти, поэтому я попытался построить модель самостоятельно. Основываясь на моем понимании того, как RTCPeerConnections передают данные между MediaStreams, я подумал о 10 местах, где время может пройти в этом потоке:
A ALICE snaps on webcam
|
| t(0)
|
RTCPeerConnection receives video+audio from ALICE MediaStream
|
| t(1)
|
RTCPeerConnection creates packet P1 containing ALICE snap
|
| t(2)
|
RTCPeerConnection starts sending packet P1 to BOB
|
| t(3)
|
BOB receives packet P1
|
| t(4)
|
B BOB plays packet P1
and at the same time, BOB snaps on webcam
|
| t(5)
|
RTCPeerConnection receives video+audio from BOB MediaStream
|
| t(6)
|
RTCPeerConnection creates packet P2 containing BOB snap
|
| t(7)
|
RTCPeerConnection starts sending packet P2 to ALICE
|
| t(8)
|
ALICE receives packet P2
|
| t(9)
|
C ALICE MediaStream plays packet P2
Если этот поток верен, разница во времени с привязкой Алисы к веб-камере и MediaStream Алисы, играющей снимок Боба, будет t(total) = t(0...9)
. Поскольку видео и аудио дорожки могут иметь свои собственные различия в синхронизации, для целей этой проблемы я в первую очередь концентрируюсь на времени, прошедшем для звуковых дорожек.
Текущая работа
Я пытаюсь выяснить, где в RTCStatsReport
эти времена могут быть представлены (путем поиска W3 API ) , С точки зрения Алисы:
MediaStreamSettings
-> latency
может оценивать t(0)
и t(5)
для локальных и удаленных потоков, но из MDN: "значение является целевым значением ; фактическая задержка может варьироваться " RTCOutboundRtpStreamStats
-> totalEncodeTime
кажется Σ t(1)
, но без возможности узнать самые последние времена RTCOutboundRtpStreamStats
-> totalPacketSendDelay
кажется Σ t(2)
, но без возможности узнать самые последние времена RTCIceCandidatePairStats
-> currentRountTripTime
, кажется, представляет t(3) + t(8)
для последнего отправленного пакета RTCInboundRtpStreamStats
- > totalDecodeTime
кажется Σ t(9)
, но без возможности узнать самые последние времена - И кажется, что
t(4)
, t(5)
, t(6)
и t(7)
будет удаленным узлом эквивалент t(9)
, t(0)
, t(1)
и t(2)
, но может быть недоступен в локальном RTCStatsReport
. По многим причинам это кажется недостаточным для Жизнеспособный способ рассчитать время.
Альтернатива:
Выглядит также, как можно рассчитать эквивалент t(0...9)
путем сравнения значений remoteTimestamp
, lastPacketReceivedTimestamp
и estimatedPlayoutTimestamp
, но смог найти только примеры, позволяющие рассчитать разницу между видео и аудио дорожками одного и того же потока, а не локального и удаленного потоков.