本地测试正常
使用mediamtx作为rtsp服务器
命令行推流
ffmpeg -re -loop 1 -i binaryPic.jpeg -c:v libx264 -f rtsp rtsp://192.168.0.169:8554/stream1
wireshark抓包分析
能看到已经有RTP协议的码流数据被抓包
查看包含SDP的包
tcp contains "sdp"
在windows宿主机上的ubuntu虚拟机上使用ffmpeg推流
ubuntu虚拟机网络配置NAT模式
mediamtx作为的服务器打印
ubuntu虚拟机推流
ffmpeg -re -loop 1 -i input.jpeg -c:v libx264 -f rtsp rtsp://192.168.0.169:8554/stream
推流命令与在宿主机windows上基本一致，除了图片名称和rtsp url地址段中路径部分有差别，基本一致
wireshark抓包分析，没有RTP码流数据，只有UDP报文。和直接在宿主机上的现象不一致
查看包含SDP的包
tcp contains "sdp"
看来SDP（会话描述协议，用于描述多媒体回话如RTSP流的参数，包括地址和端口等）。现在分析一下ubuntu虚拟机的配置的网络是NAT模式
可以得知NAT模式的网络模式下，虚拟机的ip地址与宿主机是隔离的。刚好此时宿主机和虚拟机的IP地址相同，所以出现了mediamtx作为的rtsp服务没有接收解析到RTP码流。对照一下
：windows下推流，RTP码流协议为UDP
：虚拟机ubuntu下推流
已经报错端口不可达，大概是虚拟机地址与宿主机相同导致的优先访问本地的端口，但是端口未开启导致了这个问题。（这部分逻辑通过NAT和ICMP报文报错推理）
修改windows宿主机上的ubuntu虚拟机网络配置再推流
修改为桥接模式
重新执行命令
ffmpeg -re -loop 1 -i input.jpeg -c:v libx264 -f rtsp rtsp://192.168.0.169:8554/stream
wireshark抓包
此时，发现所有地址都变成了回环地址。
因此，此时的效果确实是桥接配置的属性一致，此时未出现ICMP报错端口不可达，并抓到RTP码流包。且可以播放：
ffplay rtsp://localhost:8554/stream
总结
在本地学习实践网络视频流时，除了对码流工具或代码进行掌握之外，还需要对网络协议（如本文的rtsp协议）以及网络配置（如本文的NAT和桥接）方式有一定的了解。RTSP协议中的SDP在文中排查问题很重要，这已经是比较协议比较细节的内容了。一般只知道RTSP协议播放RTSP地址时有OPTIONS,DESCRIBE,SETUP,PLAY,TEARDOWN，进一步的理解和掌握网络协议字段的含义加快问题排查和定位。