On Tue, Apr 10, 2018 at 4:00 PM, Liu Steven <l...@chinaffmpeg.org> wrote:
> > > 在 2018年4月11日，上午3:14，Richard Shaffer <rshaf...@tunein.com> 写道： > > > > On Tue, Apr 3, 2018 at 5:11 PM, Steven Liu <lingjiujia...@gmail.com> > wrote: > > > >> 2018-04-04 7:53 GMT+08:00 Steven Liu <lingjiujia...@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@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. > > > > > Thanks, > > > > -Richard > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
