[FFmpeg-devel] [PATCH] lavf: add samba protocol via libsmbclient

Lukasz Marek lukasz.m.luki2 at gmail.com
Sun Jul 13 19:38:29 CEST 2014

On 13.07.2014 19:04, Derek Buitenhuis wrote:
> On 7/13/2014 5:54 PM, Lukasz Marek wrote:
>> You also ignored the case where user might have no access to shell at
>> all to mount remote fs.
> That's a pretty damn specialized case.
>> Also, I wouldn't like a player (or anything else) mount anything under
>> carpet on my workstation. Case when I'm forced to do it (when possible)
>> is a step backward.
> Yes but all the players *already* have SMB support more or less, which
> is where it would belongs IMO.
>> IMHO This discussion is like, lets not to add new codec to ffmpeg, user
>> may transcode file with libav for example and use it this way. You just
>> insist that there is just one way to do something and don't give any
>> other option. Maybe we should just mail samba developers to remove that
>> library, because it is not needed. Just my opinion.
> Not really. I already thought adding stuff like FTP and Gopher to libav*format*
> was out-of-scope and retarded for that library. It does not seem like the proper
> place to do such access (proper being implementing an read/seek/whatever callback
> for AVIO, which you can do even Today™).
> I'm not going to do something as silly as block this patch, I'm just stating I think
> the design decision is a poor one.

I am not sure about that. I agree it is a bit strange libavformat has 
both (de)muxers and protocols. I would expect it to be separated, but 
overall I don't don't agree it is bad ffmpeg has them at all.

Just few examples:
- ffmpeg contains not just libraries, but also tools. (ffmpeg is 
probably the most remarkable). You would need to move these protocols 
there, or have no such functionality at all. Reading some forums etc 
people seems to use it.
- implementing protocols (like ftp you mentioned) inside the project 
benefits both developers who use ffmpeg and the end user. developers 
have less work and they all possibly contribute to the project when bugs 
are found. In case all projects implement over and over the same 
functionality, there is much bigger chance more products is bugged.
- let's say there is a company X. Company X needs to release a product 
in 3 months with tons of functional requirements demanded by the client. 
Do you think they would pick minimalistic library when there is other 
that offers more? This is not just theoretical question. I saw this 
happened with ffmpeg in the company I work.

More information about the ffmpeg-devel mailing list