在用 FFmpeg RTP 传输 H.264 ,本来想着发一个帧就能收到一个帧,但测试老是反馈延迟高,我就自己测试了一下。
结果发现要接收 n 个帧,必须发送 n + 2 个帧,难顶。下面的例子之所以能收到两个是因为第二个超时了,我也不懂为什么超时就能收到第二个包。
看来得参考 RTP 自己造轮子了。
10-20 16:27:34.582 I sdp: v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 239.0.0.1
t=0 0
a=tool:libavformat 61.1.100
m=video 16384 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAHqzZQKAv+XARAAADAAEAAAMAMg8WLZY=,aOvjyyLA; profile-level-id=64001E
10-20 16:27:34.583 I send packet, pts: 0
10-20 16:27:34.600 I send packet, pts: 16666
10-20 16:27:34.617 I send packet, pts: 33332
10-20 16:27:34.617 I pkt pts: -9223372036854775808
10-20 16:27:44.629 I pkt pts: 1500
![]() |
1
ZeroW 1 天前 via iPhone
x264 preset 换成 zerolatency 试试
|
![]() |
3
wy315700 1 天前
是不是因为有 B 帧
|
![]() |
4
dosmlp 20 小时 37 分钟前
编码是有延迟的,想要实时性需要针对性调参数,比如 zerolatency
|
![]() |
8
dosmlp 18 小时 17 分钟前
媒体服务可以看看 ZLMediaKit 和 srs
|
11
rev1si0n 17 小时 9 分钟前
延迟高是不太可能的,只能是你的设置有问题,x264 有配置编码速度和延迟、比特率的选项,还有一般情况下不建议全分辨率或者全比特率编码,在合适的情况下先做一下缩放裁切再编码。做过 websocket 投屏,网络合适的情况下,从设备端到网页端渲染出图的延迟几乎不可见。
|