Hi, this is related to #9884
ExoPlayer has a feature with RTSP that if a UDP stream isn't received within a few seconds, it'll try again with TCP (Good feature)
If the server tells ExoPlayer that a UDP stream isn't available, and "RTSP/1.0 461 Unsupported Transport", it will NOT try TCP
Where this becomes a problem: If WMPlayer connects to a server with UDP available, and it doesn't receive a stream within a few seconds, it doesn't failover to TCP
I can do a work-around to tell WMPlayer clients that UDP is unavailable as a transport based on the User-Agent, but this does leave ExoPlayer clients waiting a few more seconds for video to start.
- VRChat
- AVPro (video widget)
- Windows Media API or ExoPlayer depending on platform
Is there a reason to not understand the "Unsupported Transport" response? I notice that a LibVLC supports this.
Hi, this is related to #9884
ExoPlayer has a feature with RTSP that if a UDP stream isn't received within a few seconds, it'll try again with TCP (Good feature)
If the server tells ExoPlayer that a UDP stream isn't available, and "RTSP/1.0 461 Unsupported Transport", it will NOT try TCP
Where this becomes a problem: If WMPlayer connects to a server with UDP available, and it doesn't receive a stream within a few seconds, it doesn't failover to TCP
I can do a work-around to tell WMPlayer clients that UDP is unavailable as a transport based on the User-Agent, but this does leave ExoPlayer clients waiting a few more seconds for video to start.
Is there a reason to not understand the "Unsupported Transport" response? I notice that a LibVLC supports this.