The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.
Can we get back on topic?
With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features.
Since before the fork, the libav developers have been sabotaging ffmpeg
as much as possible, in every "combat field": library names, library
versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork
anything. This is a fact. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict.
This has to stop.
ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems.
If libav and ffmpeg maintainers cannot reach an
agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav
ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and
libavcodec-libav.so, etc. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past.
And before someone mentions it: I don't think it's too late. It's getting too late because nobody with the right to act is doing anything. In the end, our users are the ones being harmed and we are left wondering why they are increasingly moving to other distributions or Mac OS X.