[FFmpeg-devel] [PATCH] Improve error-messaging with ffmpeg presets

[Måns Rullgård]

"Ramiro Polla" <ramiro.polla at gmail.com> writes:

> Hi,
>
> On Mon, Sep 29, 2008 at 6:04 PM, Stefano Sabatini
> <stefano.sabatini-lala at poste.it> wrote:
>> On date Sunday 2008-09-28 20:10:29 +0100, Robert Swain encoded:
>>> 2008/9/28 Stefano Sabatini <stefano.sabatini-lala at poste.it>:
>>> > Hi,
>>> > as in subject.
>>> >
>>> > Two hunks will correspond to two separate commits.
>>>
>>> The concept of the second hunk looks good to me. I'll let Michael
>>> decide if the code is OK.
>>>
>>> The first hunk: I think, if possible to do cleanly, it would be most
>>> informative to print the full path at which the code is looking for
>>> the file. That way the user knows where the file needs to be without
>>> looking any further into the matter.
>>
>> I don't think it's possible to do it cleanly, there are up to seven
>> places where ffmpeg looks for a preset file argument (and I think it
>> should also look in the $prefix/share/ffmpeg dir), hopefully we're
>> going to document that behaviour.
>
> Wouldn't it be easier to always expect the user to give a full path?

That wouldn't be very user friendly.

> This all started very UNIX-centric.

FFmpeg has always been UNIX-centric.  That it also works to some
extent on other operating systems is pure coincidence, and is only
supported where it requires minimal effort.

> First it expected HOME to be set.  Then more common UNIX paths were
> added. Since r15443 it now accepts UNIX absolute or relative paths,
> but it still doesn't accept Windows absolute paths (like
> c:\bla). It's growing, and growing... Maybe it would be best to
> expect the user to see a preset parameter as a file that fopen()
> will understand, and not just a magical name.

I disagree.  If msdos doesn't have any natural places to look, touch
luck for its users, but they should be pretty used to poor user
interfaces anyway.  Besides, if they have half a brain, they install
cygwin.  If they have a full brain, they install a real OS, and get
rid of msdos entirely.

I could list any number of operating systems that we do *not* support
(MacOS9, VMS, Plan9, VxWorks to name a few).  The common factor
between those that we do support, is that they have some kind of
POSIX-like interface available.  Where things start getting exotic,
our level of support tends to diminish.

Just stop pretending.  Life gets so much easier once you learn to see
the truth.

-- 
M?ns Rullg?rd
mans at mansr.com