The points on a GUI is, again, a lovely attempt at a red herring. We’re discussing the user expectations of command line interfaces, which still require design consideration, since there are norms and expectations in such interfaces. Snide insinuations about how users who somehow can’t hack a command-line should go look for a nice safe GUI is unnecessary and unproductive. I built a horizontally scalable, distributed video transcoding system complete with a RESTful web API while working for Yahoo, under the guidance of an experienced team lead who is now a director at another venture-funded video startup. Allow me to say that I know exactly what goes on under the hood here.

I’m glad you’re friends with developers of this package. They do excellent work — that has *never* been in question. If I didn’t care or understand the ffmpeg package, I wouldn’t give two cents about their software issues — I have neither the free time nor the inclination for that. I enjoy working with ffmpeg, make no mistake. The developers have simply neglected a key consideration, which is fine given their disinclination or lack of expertise in design issues; I have now raised as a critique for improvement. I don’t think they need you to defend their expertise (nor is such a defense required).

On the other hand, I certainly do not need another dose of “Free Software is awesome; to hell with the user” propaganda, or for that matter, amateur social criticism either. Fundamentally I believe in user-centered design, and it seems that you do not.

A blog comment thread is not an appropriate place for extended debate (we’ve already hit the thread nesting limit ). Please contact me by email (you can find my email over at the bottom of UC Berkeley web page) if you genuinely want to discuss the various merits of HCI principles as applied to CLI.

I personally want the guy who writes FFmpeg to focus on what he is good at and ignore graphical user interface issues. Somebody else can work on that in parallel with Fabrice Bellard and friends continuing to make a more functional / flexible CLI tool and handling new containers and data streams. FFmpeg itself is a super powerful CLI tool as it stands. No GUI designed for it could ever capture all of its flexibilty at the command-line. However, being an important piece of software, FFmpeg has had several GUIs made for it addressing various common workflows and usage.

Maybe you should investigate using one of those.

I am not surprised that even those with a Computer Science PhD background have to learn a few new tricks when dealing with Audio and Video streams processing. I know I did. One user I heard of was piping the output of ffmpeg directly into speexenc. Ingenious! Every new area of knowledge requires learning. Be open to it. The standard university way is to put such info into a man page (instead of making you read the source code). Nobody reads the whole man page everytime. And finding the information you want is a life skill. However, End Users such as yourself are not the only users of FFmpeg and similar CLI tools. Scripts use FFmpeg also. So the CLI has to service the needs of CLI people and those that want to automate the process or those that want to create a GUI for it. Why spend the time creating the GUI portion of a program that doesn’t work or a software system that nobody uses or wants to use?

That’s what you are advocating. Cart before horse.

Which is more important: the quality inside or the outside veneer? Our society already puts too much emphasis on the glitz. As I said previously, important software like FFmpeg causes software developers to embed it in scripts which make it easier to use and very important CLI utilities get several Graphical User Interfaces like FFmpeg has.

Maybe you should use the software that Sansa supplies with e2xx players for video processing .avi files into the unit’s proprietary video format. Its got a nice interface! No thinking required. No unexpected surprises.

I agree that a CLI is a user interface. One where the explanation of behaviors is documented concisely or in a form that you unfortunately can’t speed read. FFmpeg is not a system. (Quoting from your response: “intuitively designed system…”) It is a component — a part of a system. If you need a system, maybe you should investigate using an ffmpeg GUI.

The beauty of FFmpeg is that it is simple enough for you to begin using and to be quickly rewarded with fantastic results. You were hooked by the power of FFmpeg — as am I. It is worthy of our discussion. The unexpected surprise with FFmpeg is how versatile and capable a command line interface can be reusing the same switches multiple times for different purposes. Truly it is the swiss-army knife of audio/video processing. Be glad these Linux utilities and libraries are now available on Windows. And that OSS developers have the freedom to work on what they deem most important.

Being open source does not excuse bad user interface design. Actively confusing interfaces — interfaces that function contrary to user expectations — creates errors where none needed to exist. If you check the About page here for my background, you’ll find that my “cred” on software and technology issues to be significant (Berkeley PhD work, startup founder, engineer, etc.). Nevertheless, I made this error, because my expectations on how a CLI should behave — drawn from years of experience — is violated in idiosyncratic and largely needless ways. Ironically, had I *not* been a regular CLI user, I might not have formed this particular expectation. Nevertheless, the key target audience of a tool like ffmpeg is precisely an experienced CLI user.

The man page is a red herring. The need to refer to or post signage is practically *already admitting* that you have made an design error, or at least made some incomprehensible design choices in the eyes of your typical user. An intuitively designed system does not require warnings, because of the affordances of such systems naturally guides user into making correct choices or decisions. I won’t even get into the matter of requiring the reading of an entire document vs simple signage, which at least has the possibility of being effective at educating a user.

I highly recommend Don Norman’s book “The Design of Everyday Things” (and its companion, Emotional Design: Why We Love Or Hate Everyday Things). This is a book that every would-be software engineer should read before they start taking on any sort of software design or architect role. Every HCI designer already starts with it as the introductory text, and I think every engineer should have to read this as well. It explains in an extremely lucid and well-reasoned way why certain designs succeed and others fail. It certainly changed my views (similar to your own, once) on how human-facing interfaces should be designed, and where the responsibility for user errors lies.

And yes, I will reiterate: even CLIs are user interfaces.

The difference between Propaganda and Education is that Propaganda tells you what to think and Education (and Open Source) teaches you how to think.

In man page of ffmpeg it is specified that parameters concerning the source file -i SOURCE_FILE need to be before it.
But people do not read man pages.
They use google and copy-paste.

I’ve lost hours trying to cut the useless parts of a .TS file, and I couldn’t understand why ffmpeg was re-encoding everything (in crappy quality). I could have managed to find the “copy” codecs, but putting -ss on the beginning was beyond my imagination.

I agree with yiming: command line should be as much as possible order-neutral, and sanity checks MUST occur.

This sort of problem should be detected, and a warning printed to standard error. In most cases, it makes no sense to accept -t or -ss options for an output file rather than an input file, making detection quite easy for the majority of cases. It is the responsibility of ffmpeg to do this, because here it is ffmpeg that is behaving out of the norm, not the user.

Imagine if I designed a doorknob — which looks like an ordinary doorknob — but requires that you pull/push on the knob to open, rather than turning it. I would expect that many users would be confused when they first try any door with this knob installed. If my oddly designed doorknob is used in all major buildings, users may indeed write blog posts about how unintuitive it is. And assuming that I cannot redesign my doorknob at all, I would post a sign that says “Pull to open”, rather than putting a 10-page operating manual (complete with diagrams) next to every such door, with a guy next to it yelling “Read the F’ing Manual!”

In “ffmpeg -ss 00:00:30.00 -t 25 -i bar.mp3 -acodec copy bar-new.mp3″ the -ss and -t option apply to bar.mp3 and the -acodec applies to “bar-new.mp3″.

Look at this one (capture from webcam) to dvd mpeg:”ffmpeg -f mjpeg -s 464×480 -vcodec mjpeg -r 14 -i /dev/video0 -target pal-dvd ~/stream.mpeg”