[FFmpeg-devel] [PATCH] sftp: support reading config from ~/.ssh/config

[Florian Jacob]

Am Mittwoch, 11. März 2015, 10:27:55 schrieb Reimar Döffinger:
> On 11.03.2015, at 10:13, Florian Jacob <projects+ffmpeg at florianjacob.de> 
wrote:
> > 11.03.2015, 00:51:39 by Timothy Gu:
> >> Does this patch change the default behavior in any way?
> > 
> > No, at least it's not intended to change for users who don't have a
> > ~/.ssh/config.
> > 
> > If there are users who have a config lying around and expecting it to be
> > ignored, let's say they don's specify a username in the sftp:// url and
> > expect the default value to be used while they have non-default config
> > setting, the behaviour changes.
> > 
> > But I think that's hypothetical, users who have an ssh config are probably
> > replicating their settings explicitely in their current sftp:// urls.
> 
> Well, I can think of one case: users that enable compression in the config
> file. That makes sense for interactive session and when copying normal
> files, but for multimedia it is mostly nonsense.

Good thought. With the patch, it's possible for the user to use a separate 
config for turning compression off, through hostname aliases and differentiated 
by the hostname that the user uses to connect. For example:

Host example.com
    Port 12345

Host example-nocompression
    Hostname example.com
    Port 12345
    Compression no

and then use

ffplay "sftp://example-nocompression/path/to/video.mkv"

This way, the user can configure that they don't want to use compression for 
ffmpeg (or anything else where they use example-nocompression as a hostname)

> Do we have a way to apply
> ffmpeg-specific options?
We can force to use no compression in the code, by adding this line:

ssh_options_set(libssh->session, SSH_OPTIONS_COMPRESSION, "no");

after parsing the config file. I just looked into the config parsing code, 
changes to the compression options before parsing will actually be overwritten 
by the config file. This would also mean that the user can't configure to use 
compression for ffmpeg even if they want to, though, but this wasn't possible 
before either.

> If so, should they default to disabling compression?
I only use ffmpeg to play videos in already-compressed formats, so it would 
make sense in my use case, but I don't know whether ffmpeg can be used in a way 
where you would actually want ssh compression.

One might could argue that connections that benefit and work faster with the 
compression option are too slow to stream media, anyway.

Other thoughts?


I can send in another patch if wanted.