这是一个创建于 56 天前的主题，其中的信息可能已经有所发展或是发生改变。
在用 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 6.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 56 天前 via iPhone x264 preset 换成 zerolatency 试试 |
 | 3 wy315700 56 天前 是不是因为有 B 帧 |
 | 4 dosmlp 55 天前 编码是有延迟的，想要实时性需要针对性调参数，比如 zerolatency |
| 8 dosmlp 55 天前 媒体服务可以看看 ZLMediaKit 和 srs |
 | 11 rev1si0n 55 天前 延迟高是不太可能的，只能是你的设置有问题，x264 有配置编码速度和延迟、比特率的选项，还有一般情况下不建议全分辨率或者全比特率编码，在合适的情况下先做一下缩放裁切再编码。做过 websocket 投屏，网络合适的情况下，从设备端到网页端渲染出图的延迟几乎不可见。 |
Select Language