[FFmpeg-devel] [PATCH] avformat/hls: copy rw_timeout from parent to child AVIOContexts.

[Steven Liu]

> On 11 Apr 2018, at 07:13, Richard Shaffer <rshaffer at tunein.com> wrote:
> 
> 
> 
> On Tue, Apr 10, 2018 at 4:00 PM, Liu Steven <lq at chinaffmpeg.org> wrote:
> 
> > 在 2018年4月11日，上午3:14，Richard Shaffer <rshaffer at tunein.com> 写道：
> >
> > On Tue, Apr 3, 2018 at 5:11 PM, Steven Liu <lingjiujianke at gmail.com> wrote:
> >
> >> 2018-04-04 7:53 GMT+08:00 Steven Liu <lingjiujianke at gmail.com>:
> >>>>>
> >>>>> Look at the code:
> >>>>>
> >>>>> 205     char *referer;                       ///< holds HTTP referer
> >> set
> >>>>> as an AVOption to the HTTP protocol context
> >>>>> 206     char *user_agent;                    ///< holds HTTP user
> >> agent
> >>>>> set as an AVOption to the HTTP protocol context
> >>>>> 207     char *cookies;                       ///< holds HTTP cookie
> >>>>> values set in either the initial response or as an AVOption to the HTTP
> >>>>> protocol context
> >>>>> 208     char *headers;                       ///< holds HTTP headers
> >> set
> >>>>> as an AVOption to the HTTP protocol context
> >>>>> 209     char *http_proxy;                    ///< holds the address of
> >>>>> the HTTP proxy server
> >>>>>
> >>>>> There have some comment for the options.
> >>>>> and reference the code in: hls_read_header / open_input and use the
> >>>>> options.
> >>>>>
> >>>>>
> >>>> That's pretty clear. What I was asking is why the options are stored
> >> both
> >>>> in these fields as well as avio_opts, and this doesn't answer my
> >> question.
> >>>> I was also asking why you object to storing the timeout option in
> >>>> avio_opts, but I'm not understanding the logic in your responses.
> >>>
> >>> no logic problem, just that option be used to HTTP, is that ok?
> >>
> >
> > This is a logic problem for me, because I'm not understanding your logic.
> > What is the reason that avio_opts should only be used for HTTP options?
> >
> >
> >>>
> >>> BTW, how should i reproduce the problem you said?
> >>
> >
> > If you pass the rw_timeout option to either the command-line or to
> > avformat_open_input, it will be applied only to the URL passed on the
> > command line or to the function. When the HLS demuxer tries to open other
> > URLs, such as keying URIs, media playlists or segments, it will not apply
> > the rw_timeout option. As a result, if we fail to receive data from the
> > remote server, it can block the process instead of returning the expected
> > AVERROR(ETIMEDOUT) error.
> >
> >
> >>>
> >>> "
> >>> The rw_timeout option is currently not applied when opening media
> >> playlist,
> >>> segment, or encryption key URLs. This can cause the HLS demuxer to block
> >>> indefinitely, even when the rw_timeout option has been specified. This
> >> change
> >>> simply enables carrying over the rw_timeout option when the demuxer
> >> opens these
> >>> URLs.
> >>> "
> >>
> >> So i think add option timeout to do it maybe better than this way. you
> >> can find another formats do it like this.
> >>
> >
> > I think the HLS demuxer is pretty unique. Except for dash, I don't know
> > which other demuxers have to open additional avio to do their work. If
> > there is an example you can show me that illustrates your point, that would
> > be appreciated.
> >
> >
> >>>
> >>>>
> >>>>
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel at ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Hi Steven,
> >
> > I apologize for the late response. I have been traveling.
> >
> > I understand that you might be busy, and that English is not everyone's
> > first language. However, if you could take the time to give a more thorough
> > response, I'd really appreciate it. It's a little bit frustrating for me:
> > I'm asking why avio_opts needs to be restricted to HTTP options, and the
> > answer I seem to keep getting back is "because it's for HTTP options." That
> > answer isn't very satisfying, and doesn't help me understand /why/ you
> > think it should only be used for HTTP options. It may be that you have a
> > good reason, but if I can't understand what it is, I'm not going to be able
> > to provide a better fix.
> >
> > I can't force anyone to accept my changes or provide more detailed
> > feedback. However, if we can't understand each other, then at some point I
> > will have to give up. I'll apply a patch that fixes my problem to a local
> > fork of ffmpeg. Other people outside of my company won't benefit from the
> > fix. My company will also have to maintain our own copy of ffmpeg. This
> > could make it less likely for us to share our changes with the community,
> > and it will also make it harder for us to benefit from improvements and
> > fixes to ffmpeg. I don't want to do that, because nobody wins in that
> > scenario. That is why I'm asking for your help to understand your objection
> > and suggestion.
> 
> Sorry for my poor English, English is not my first language, thanks, you can contribute.
> After the last patch you submit(https://patchwork.ffmpeg.org/patch/8378/), i think i can understand this patch.
> 
> Thanks, Steven. I will wait a few days. If there are no additional comments, I will ask you or another maintainer to apply the patches.
pushed
> 
> >
> > Thanks,
> >
> > -Richard
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven