[Bug] SRT: SRS does not respect peer_idle_timeout

[artem-smorodin-dacast]

This is the same issue as #3511, which has not been fixed.

It seems that SRS does not respect peer_idle_timeout currently, a constant value of 5 seconds is used.

I think we should set this timeout at both the socket level and the application level, otherwise it doesn't make sense. If peer_idle_timeout exceeds 5 seconds, the connection will be closed due to hardcoded application timeout being reached.

recv_timeout_ = 5 * SRS_UTIME_SECONDS;
send_timeout_ = 5 * SRS_UTIME_SECONDS;

Which are set here

Timeout will be reached here

I debugged this and can confirm that this is the case.

[winlinvip]

See 18c30dc#diff-f7d29d8d908a2f45e9baa90df43bef367011f53469bad0550a9a503a40c9287c

srs_utime_t timeout = config_->get_srto_peeridletimeout();
bool has_msgs = consumer->wait(1, timeout);

If you suppose it's a bug, please provide detail steps to reproduce it, don't just describe the issue with code.

[artem-smorodin-dacast]

@winlinvip Please look at the link "Timeout will be reached here" and make sure that no code sets recv_timeout_ for publisher.

If you need steps to reproduce, here they are:

1. Set peer_idle_timeout 60000;
2. Run ffmpeg ffmpeg -re -i "bbb_sunflower_2160p_60fps_normal.mp4" -c copy -pes_payload_size 0 -f mpegts 'srt://127.0.0.1:10080?streamid=#!::r=live/test,m=publish''
3. In another terminal, run pkill -STOP ffmpeg; sleep 10; pkill -CONT ffmpeg

After that you receive an error srt socket XXX timeout

The expected behavior in this case is that ffmpeg will continue streaming.

It works as expected if I manually increase the hardcoded values for recv_timeout_

But it is also enough to simply set a breakpoint and see that recv_timeout_ is equal to a hardcoded value regardless of the value of peer_idle_timeout.