Now that I have tested this:
On Sat, Jun 13, 2020 at 23:17:41 +0800, leviz...@live.cn wrote:
> #endif /* !HAVE_WINSOCK2_H */
> + char *socks_proxy;
> } TCPContext;
[...]
> { "listen", "Listen for incoming connections", OFFSET(listen),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
> + { "socks_proxy", "set socks proxy for connection",
> OFFSET(socks_proxy), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0,
> .flags = D },
> { "timeout", "set timeout (in microseconds) of socket I/O
> operations", OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1, INT_MAX, .flags = D|E },
You're not using this variable anywhere. So the introduced command line
option is dead.
> + proxy_path = getenv("socks_proxy");
> + use_proxy = proxy_path && av_strstart(proxy_path, "socks5://", NULL);
> + if(use_proxy) {
And here's the reason:
You use the environment variable only.
Furthermore, I'm not sure this is the proper convention for specifying
a SOCKS proxy in the environment. I found various other suggestions
around the net, but not this one. Please don't invent one, instead make
the command line option functional.
> .url_open = tcp_open,
> + .url_open2 = tcp_open2,
If the url_open2 function pointer exists, url_open will never be used.
So you should be writing a *replacement* function for tcp_open(), not
an amendment.
Actually, since your tcp_open2() doesn't even use the "options"
argument, it would be a url_open callback. url_open2: "This callback is
to be used by protocols which open further nested protocols." I think
this does not apply to the "tcp" protocol.
Therefore, you should merge the socks functionality into the existing
tcp_open().
I would also appreciate a log message (at level verbose or debug),
indicating that a SOCKS "redirection" is taking place. Otherwise,
there's a seemingly random mismatch between the URI's hostname and the
logged IP/port.
All this said, when using the environment variable, I managed to get
ffmpeg to connect to an http:// and an https:// input URL (HLS) through
a SOCKS5 proxy. So at least it works. Thanks for your effort so far.
Regards,
Moritz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
