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

Jun Li junli1026 at gmail.com
Thu Apr 11 06:55:37 EEST 2019


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.


More information about the ffmpeg-devel mailing list