[FFmpeg-devel] [PATCH] avformat/rtmpproto: forward rw_timeout to tcp proto

[Martin Storsjö]

On Thu, 20 Jul 2023, Timo Rothenpieler wrote:

> On 20.07.2023 22:47, Martin Storsjö wrote:
>> On Thu, 20 Jul 2023, Timo Rothenpieler wrote:
>> 
>>> ---
>>> libavformat/rtmpproto.c | 10 +++++++---
>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>> 
>> Hmm, I would have somewhat expected that rw_timeout should be honored 
>> here already...
>> 
>> Note that URLContext already has got a rw_timeout field and AVOption, so 
>> instead of adding a new option, it should be enough to just use the 
>> existing URLContext field.
>> 
>> But also, have a look at fab8156b2f30666adabe227b3d7712fd193873b1. When 
>> opening a chained URLContext, we pass in the parent one, and propagate 
>> any options from that URLContext into the child. So as long as the 
>> URLContext rw_timeout is set for the rtmp protocol, the nested tcp 
>> protocol also should be getting it already implicitly.
>
> I'm not entirely sure how that works with in regards to which options 
> are getting forwarded where.
> But doesn't the "timeout" (in seconds, used as listen timeout) option 
> from rtmpproto mask over the "timeout" option from tcp (in microseconds, 
> used as rw/open timeout)?
> Hence the "renaming" here, to unshadow that tcp.c option.

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.

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

// Martin