它遵循我尝试实现适当方式的设计:我有一个JavaScript对等方,正在向Native Code对等方发送视频轨道。在传输过程中的某个时刻(实际上是在建立连接后立即,但是可能随时会出现),我想在JS对等端启动一个秒表并执行一些临时化的操作,实际上是在画布上进行一些渲染以覆盖视频播放。在本机对等端,我希望能够在秒表从JS对等点开始的瞬间进行同步,并只考虑该瞬间之后记录的接收帧,并执行其他某种处理。我现在正在做什么(脆弱而局限的解决方案):
RTCPeerConnection.iceConnectionState
后,我就在JS同级上启动秒表; webrtc::VideoFrame
到达本地对等体后,我便存储了帧时间垃圾邮件; 这种设计是有局限性的,因为我可能想在任何时刻进行同步,而不仅是在对等体连接建立上进行同步,而且还很脆弱,因为我认为出于任何原因(延迟或传输错误),都允许WebRTC协议丢弃最早接收到的帧)。理想情况下,我想在JS对等体中选定的同步点处添加一个时间戳,并将其发送给本机对等体,并能够比较webrtc::VideoFrame
时间戳。我无法天真地执行此操作,因为VideoFrame::timestamp_us()
明显偏斜了一些我不知道的数量。另外,我无法解释VideoFrame::timestamp()
,该文档在api/video/video_frame.h
中的记录很少,VideoFrame::ntp_time_ms()
已过时,实际上总是返回-1
。我该怎么做才能在两个对等方之间实现这种同步?
答案 0 :(得分:0)
可以通过将NTP 发件人时间中的同步事件时间戳发送给接收器来正确实现设计。然后,接收者必须能够估计帧上的发送者NTP时间戳,并将其与同步事件的时间戳进行比较。支持此方法的概念证明补丁已存在,并已在此跟踪issue中推送到Native WebRTC项目。更多细节在以后。