On 20.07.2023 23:09, Martin Storsjö wrote:
Hmm, geez we have many similar-looking and randomly named timeout options here...

The av_opt_copy() call in ffurl_open_whitelist() should only iterate over the options within the URLContext itself, not recurse into the protocol private options (as those probably don't match across protocols anyway). So I wouldn't think that the tcp "timeout" option ends up implicitly set from the rtmpproto "timeout" (listen_timeout) option.

My goal here is to specifically be able to set the i/o timeout on the tcp side, since I just had an ffmpeg rtmp process wait for more data indefinitely after a network hickup, even though the connection was long dead.

I just discovered that the URLContext has global options, and rw_timeout is one of them. So setting -rw_timeout should have already been possible, I'll try if that ends up in the right place.

I didn't try running and observing it right now though.

// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to