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

Richard Shaffer rshaffer at tunein.com
Tue Apr 10 22:14:43 EEST 2018

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

> >
> > "
> > 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.



More information about the ffmpeg-devel mailing list