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

Jun Li junli1026 at gmail.com
Tue Apr 9 06:19:06 EEST 2019


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


More information about the ffmpeg-devel mailing list