> 在 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, > > -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
