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? > > BTW, how should i reproduce the problem you said? > > " > 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. > >> >> _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
