你们测评过jetson系列“硬件编码推流-公网传输-解码”这个loop的时延么?

  • 1 replies
  • 391 views
*

sisiy

  • *****
  • 240
    • 查看个人资料
你们测评过jetson系列“硬件编码推流-公网传输-解码”这个loop的时延么?

*

sisiy

  • *****
  • 240
    • 查看个人资料
答复: 这等于说,要测试: (1)视频源编码延迟 + (2)移动/联动/电信等家的公网的传输延迟 + (3)接收端的解码延迟;
其中(2)和各地的网络情况有关,可能是这里面最大的一个延迟。而只有(1)和(3)是和我们的Jetson系列产品有关的。其中(1)进一步的分为视频源自身的延迟(USB摄像头/CSI摄像头/IP摄像头(RTSP的)),和硬件的nvenc的编码引入的延迟。而(3)基本只涉及NVDEC的硬件解码器自身的延迟。所以想回答这个问题,需要逐个测试这些。然后相加(在某种典型的硬件配置和运营商网络的案例下)才能得到。

根据其他客户之前的测试,RTSP的摄像头,也就是我们常说的IP摄像头,延迟非常严重,肉眼可见,挥动手就能看出来,估计几百ms。其他的两款摄像头应该都非常低,最低的应该是CSI的,但具体数值没有。所以问题就剩下了运营商网络的传输延迟,和NVENC/NVDEC的编码/解码延迟。

注意:RTSP的延迟高基本上是国产摄像头的问题。以及,考虑到RTSP内部已经编码过一次了(264或者265),如果不是为了减少传输量的话,也可以不经过NVENC的第一步,直接开始第2步的传输。所以如果是这种情况,可以考虑再减掉这个编码的时间,从第一步里。
(但是国产的摄像头很多用的海思芯片,编码真心渣渣,也许转码一次降低的传输量对应的时间,反而更加合算,但是具体如何,得测试,现在只是猜测)