We should distinguish avconv/ffmpeg with -version

[FiloSottile]

This is a low priority, but is the only solution to the symlinks mess that are some current distribution packages.

[phihag]

Sorry, I don't understand this issue. What exactly is the problem of symlinked versions of aconv/ffmpeg? And why can't we simply use the ffmpeg binary when it's there, and avconv if it's not?

[FiloSottile]

For example in Ubuntu, ffmpeg is a symlink to avconv. At the moment we are handling this simply giving priority to ffmpeg, but one can have the opposite situation on a system, and we would consider avconv as ffmpeg then. And we can't ignore symlinks as they are common in $PATH. Maybe following them and looking at the original executable name?

[phihag]

Oh, I think I misunderstood; I didn't realize the APIs of aconv and ffmpeg differ. Isn't there a common subset we can use?

In any case, that's not a problem by convention: If the user (or the distribution) implements ffmpeg with a symlink to another program, that other program better accept ffmpeg-style arguments.

Therefore, instead of trying to go down the rabbit hole of how one program may call another (what if ffmpeg is a shell program exec avconv "$@"? What if it's a hardlink? ...), we should take care to restrict our arguments to what is widely accepted, and report bugs to the distributions (say, if ffmpeg foo.mp3 -i foo.mp4 suddenly fails because they decided to symlink ffmpeg to mencoder).

[FiloSottile]

Unfortunately, a couple of things we use are actually incompatibile. Will have to check better, thought.