Regression UDP/RTSP: UDP timeout never hits

[Chris R]

Summary of the bug:
How to reproduce:

ffprobe -i rtsp://x.x.x.x:554/axis-media/media.amp
2022-05-23-git-6076dbcb55
works on 4.3.2, broken on 4.4 and above

On previous releases ffmpeg would fail over to TCP when a UDP timeout got hit. The timeout no longer gets hit.

On 4.3.2, after a few seconds waiting on UDP, the message "[rtsp @ 0000022607bcd4c0] UDP timeout, retrying with TCP]" pops up, and attempts TCP.

I believe this is due to the UDP option overwriting timeout, and ends up being infinitely long.

You can work around this by specifying "-timeout 2000000" for instance.
"-rw_timeout 2000000" however does not work for this scenario.

It would be very nice to have the working failover back, as the default (UDP) lower_transport is not always implemented properly, or available at all, causing it to outright fail after waiting several minutes.

Example of working and non-working ffmpeg in this scenario:
​https://gist.github.com/flaeri/6c8eb5532f9cee56bc25d7032c0e9d2e

[Andriy Gelman]

-timeout is the right option to use. But default is currently 0 (or infinite timeout), which is why it's not automatically switching to tcp lower transport.

There is a patch to change the behavior back to a default timeout of 10 seconds:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201115182005.24702-4-andriy.gelman@gmail.com/

[Chris R]

Replying to Andriy Gelman:

-timeout is the right option to use. But default is currently 0 (or infinite timeout), which is why it's not automatically switching to tcp lower transport.

There is a patch to change the behavior back to a default timeout of 10 seconds:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201115182005.24702-4-andriy.gelman@gmail.com/

Thank you very much. I do however believe that the timeout used to be somewhere close to 2-3 seconds, 5 at most. I'm not saying that this is for sure the way to go, but 10 seconds seems fairly long to me. If the connection has not managed to get established in 5 seconds, I have my doubts that it will ever manage. Personally I would prefer a lower timeout.

[Chris R]

Replying to Andriy Gelman:

-timeout is the right option to use. But default is currently 0 (or infinite timeout), which is why it's not automatically switching to tcp lower transport.

There is a patch to change the behavior back to a default timeout of 10 seconds:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201115182005.24702-4-andriy.gelman@gmail.com/

Thank you very much. I do however believe that the timeout used to be somewhere close to 2-3 seconds, 5 at most. I'm not saying that this is for sure the way to go, but 10 seconds seems fairly long to me. If the connection has not managed to get established in 5 seconds, I have my doubts that it will ever manage. Personally I would prefer a lower timeout.