[FFmpeg-devel] [PATCH] Adding support for OSX bundles to ffmpeg command line

Chris Marrin chris
Sun Mar 22 03:41:05 CET 2009

On Mar 21, 2009, at 8:26 AM, Robert Swain wrote:

> On 21/3/09 14:20, Chris Marrin wrote:
>> On Mar 21, 2009, at 6:53 AM, M?ns Rullg?rd wrote:
>>> vmrsss <vmrsss at gmail.com> writes:
>>>> Wouldn't it be simpler and more flexible to have an env var  
>>>> which, if set, overrides the standard ~/.ffmpeg and /usr/local/ 
>>>> share/
>>>> ffmpeg preset locations?
>>> Not overrides, precedes. The search order should be same as for any
>>> typical Unix application:
>>> 2. ~/.ffmpeg
>>> 3. $prefix/share/ffmpeg
>>> I'm sure there some reason this wouldn't work on macos of course, it
>>> being from apple and all. I don't know what these bundles are, let
>>> alone how they work.
>> Ah. So that's it. You hate Apple, so anything that helps ffmpeg work
>> better on OSX is bad? That's a dangerous attitude for a tool that
>> purports to be a universal solution to video encoding. It's  
>> unfortunate
>> you felt the need to bring prejudice into a technical discussion.
>> Being as this is my first attempt at submitting a patch to ffmpeg, I
>> have to say that the response has been pretty disappointing and
>> surprising. FFmpeg is a great tool with an active support  
>> community. I
>> would have though the environment would be a bit less hostile. Oh,  
>> well.
>> I still like the tool.
> People are free to hate whatever they like (oxymoronic phrasing but  
> you know what I mean) and to be vocal about it.
> Most of your interactions throughout your submission have been with  
> M?ns and he is known to be one of the more abrasive people within  
> the community. This doesn't make him less valuable as an FFmpeg  
> developer, though it may make his responses less helpful and better  
> taken with a pinch of salt. :)

I appreciate the response. I'm usually thicker skinned. But I work for  
Apple and when someone steps off about the mothership, I'm  
contractually obligated to respond with guns blazing. :-)

> Personally, I don't like the hostility and if you read back through  
> the mailing lists I have campaigned against it previously. The main  
> things that one can note when making submissions to FFmpeg are that  
> some people here are abrasive, comments should not be taken  
> personally and perseverance may well be necessary to succeed both  
> because we have exceptionally high standards, that often seem to  
> border on unnecessary pedantry, and because sometimes it takes  
> perseverance to get useful information out of people to attain the  
> high standards demanded.

I want to make it clear that I wasn't put off by the fact that my  
patch was getting criticized. I would expect a project like this to be  
very careful about submissions. I'd just like the criticism to be  
constructive so I can try to make an acceptable contribution. As far  
as separating indentation vs. functional changing, I can deal with  
that. I've just never seen it before.

>> For the record, using an environment variable is a better solution
>> (thanks to vmrsss for that). Maybe I'll try it at some point. But I
>> don't really have any more time for patch submission, so for now I'll
>> continue just using my existing customized version which is fine  
>> for my
>> use case.
> A patch for this would definitely be welcome and then you could  
> script something in your bundle to dynamically set the environment  
> variable depending on from where the .app is run.

Yeah, I can do that. For the record, there is nothing magical about  
bundles. They are just directories where you can package up all the  
the files for your app. OSX treats these specially: XCode knows how to  
collect files into bundles, Finder knows how to execute the app in a  
bundle, etc. Adding something to ffmpeg to help with bundles is just  
making it possible to place ffpresets relative to the executable (and  
therefore relative to the bundle) rather than requiring them to be  
placed in fixed system directories.

Anyway, thanks again...

chris at marrin.com

More information about the ffmpeg-devel mailing list