我有一个用例，我需要重新播放RTSP URL。
对于以下所有情况，Live555都是通过克隆源来在本地构建的。
对于以下所有情况，将在各个服务器中为RTSP打开所需的端口。
首先，我使用Live555MediaServer设置要流式传输的文件。这是在AWS实例（AWS1）中。
./Live555MediaServer ashi.webm给出了
rtsp://public_IP_of_instance:8554/ashi.web
通过尝试在VLC播放器中播放来检查传入流是否正常工作。这个传入的流工作正常，在VLC上运行良好。
现在，为了重新播放，我尝试了Live555ProxyServer。现在，通过在Mac上运行Live555ProxyServer，将来自AWS1的传入流重新声明到另一个URL。
./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web给出，
rtsp://localhost:8554/ProxyStream
此URL也可在VLC中播放。
现在我设置另一个AWS实例（AWS2）并在其上运行ProxyServer，监听AWS1。
即，
./Live555ProxyServer rtsp://public_IP_of_instance_one:8554/ashi.web给出，
rtsp://public_IP_of_instance_two:8554/ProxyStream
此网址无法播放。
我尝试使用-t标志代替TCP而不是UDP。我尝试使用ffprobe检查传入的RTSP流，并且流显示了所有必需的详细信息。
可能的原因是什么？这条管道中缺少的是什么？我们是否拥有优秀的行业级开源RTSP服务器？
编辑：
我不知道究竟发生了什么，但是使用VLC作为客户端检查流是问题所在。我移动到ffmpeg并尝试使用
ffmpeg -i rtsp://public_IP_of_instance_two:8554/proxyStream -acodec copy -vcodec copy abc.webm
所以来自ProxyServer的流很好。
客户端更改导致的是live555ProxyServer关于过时固件解释here的反复警告。
我目前正在Mac中使用VLC版本3.0.3 Vetinari（Intel 64位），这是最新版本。也许VLC在内部使用旧版Live555。