[FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel

[Liu Steven]

> 在 2019年4月11日，上午11:55，Jun Li <junli1026 at gmail.com> 写道：
> 
> On Mon, Apr 8, 2019 at 8:19 PM Jun Li <junli1026 at gmail.com> wrote:
> 
>> On Mon, Apr 8, 2019 at 6:23 PM Liu Steven <lq at chinaffmpeg.org> wrote:
>> 
>>> 
>>> 
>>>> 在 2019年4月9日，上午8:54，Jun Li <junli1026 at gmail.com> 写道：
>>>> 
>>>> Ping.
>>>> 
>>>> On Fri, Apr 5, 2019 at 12:00 PM Jun Li <junli1026 at gmail.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Apr 5, 2019 at 11:50 AM Jun Li <junli1026 at gmail.com> wrote:
>>>>> 
>>>>>> stimeout option is already used in tcp transport, since
>>>>>> http is based on tcp, pass the option to http for tunneling
>>>>>> case.
>>>>>> ---
>>>>>> libavformat/rtsp.c | 10 ++++++++--
>>>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>>> 
>>>>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>>>> index 033095905d..8349840c96 100644
>>>>>> --- a/libavformat/rtsp.c
>>>>>> +++ b/libavformat/rtsp.c
>>>>>> @@ -1744,6 +1744,9 @@ redirect:
>>>>>>        char httpname[1024];
>>>>>>        char sessioncookie[17];
>>>>>>        char headers[1024];
>>>>>> +        AVDictionary *options = NULL;
>> 
>> 
>> 
>>>>> +
>>>>>> +        av_dict_set_int(&options, "timeout", rt->stimeout, 0);
>>>>>> 
>>>>>>        ff_url_join(httpname, sizeof(httpname), https_tunnel ?
>>> "https" :
>>>>>> "http", auth, host, port, "%s", path);
>>>>>>        snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
>>>>>> @@ -1774,7 +1777,8 @@ redirect:
>>>>>>        }
>>>>>> 
>>>>>>        /* complete the connection */
>>>>>> -        if (ffurl_connect(rt->rtsp_hd, NULL)) {
>>>>>> +        if (ffurl_connect(rt->rtsp_hd, &options)) {
>>>>>> +            av_dict_free(&options);
>>>>>>            err = AVERROR(EIO);
>>>>>>            goto fail;
>>>>>>        }
>>>>>> @@ -1818,10 +1822,12 @@ redirect:
>>>>>>        ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
>>>>>> 
>>>>>>        /* complete the connection */
>>>>>> -        if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
>>>>>> +        if (ffurl_connect(rt->rtsp_hd_out, &options)) {
>>>>>> +            av_dict_free(&options);
>>>>>>            err = AVERROR(EIO);
>>>>>>            goto fail;
>>>>>>        }
>>>>>> +        av_dict_free(&options);
>>> Why don’t move the av_dict_free(&options) to the fail?
>> 
>> 
>> 
>> Since the diff does not show the whole picture of the code, I simplify the
>> code as follows:
>> 
>>      if (is_tunnel) {
>>             AVDictionary *options = NULL;
>>             .....
>> 
>>             if (err) {
>>                   av_dict_free(&options);
>>                   goto fail;
>>             }
>>             av_dict_free(&options);
>>      } else {
>> 
>>      }
>> 
>> fail:
>>     // some clean-up code.
>> 
>> 
>> So if I put the "av_dict_free" in the fail, then I have to put the
>> "options" declaration outside of the if condition, to expand its scope so
>> that clean-up code can see/use.
>> Option 2 is to add a label tunnel_fail like this:
>> 
>>      if (is_tunnel) {
>>             AVDictionary *options = NULL;
>>             .....
>>             ......
>>             if (err) {
>>                   goto tunnel_fail;
>>             }
>> 
>> *tunnel_fail: *
>>             av_dict_free(&options);
>>             if (err) {
>>                  goto fai;
>>             }
>>      } else {
>> 
>>      }
>> 
>> fail:
>>     // some clean-up code.
>> 
>> 
>> The "tunnel_fail" label may be a little heavy if it is just for
>> "av_dict_free". But it still has its point.
>> And option 1 -- move the variable scope outside of the if condition is
>> also a little heavy.
>> What do you think ?
>> 
>> 
>> 
>>>>>    } else {
>>>>>>        int ret;
>>>>>>        /* open the tcp connection */
>>>>>> --
>>>>>> 2.17.1
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Updated the version, free the memory in error path, patch is here:
>>>>> https://patchwork.ffmpeg.org/patch/12620/
>>>>> I initially planned to do that then I realized the error path will
>>> trigger
>>>>> whole process to exit, which may be safe. But I agree with you, it is a
>>>>> better practice to clean-up here.
>>>>> 
>>>>> Thanks for review, Michael.
>>>>> 
>>>>> Best Regards,
>>>>> Jun
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel at ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>> 
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe”.
>>> 
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> Steven
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>> 
>> 
>> Thanks for review Steven !  I commented in-line.
>> 
>> Best Regards
>> -Jun
>> 
> 
> Ping.
LGTM
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".