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".
