I still think this is a packaging issue. ffmpeg 1.1 is certainly not the latest version, rpmfusion uses 2.1.1, upstream has released the 2.1.4 tarball. Yet rpmfusion is able to provide the proper compatibility libraries in ffmpeg-compat; there is really no point updating those from current state.
If rpmfusion can I guess Gentoo can as well.
That said, if they just use a dlopen() without quirks the they will first try loading from same directory as the binary (it has a $ORIGIN rpath). So if you could get the hands on the proper 0.52/0.53 libraries I think they will be used if put in same place as where you have the binary. It certainly works for normal, dynamic loading done by ld.so.
I agree that that it would be better if the devs answered this. It's just that they so far doesn't; it's kind of a habit. To be frank, I doubt they even read it - there are no signs whatsoever on that so far.
It seems what it's missing is libavutil.so.51 The libraries that appeared missing from the test with ffmpeg-compat libraries seem that were dependencies from that libavutil, but it worked just fine with the shared libraries that libav 0.8.10 builds when it's compiled from source with the --enable-shared flag (./configure --help will give you all the options to enable different codecs).
Copied libavcodec.so.53 and strace showed that it was still calling to libavutil.so.51. Copied that too and that did the trick.
The names seems that are hardcoded so I didn't need to create symlinks without the soname version.
This could mean that if you compile your libav-0.8.10 without installing it (preferred method) one could just add the paths to these libraries in a file in /etc/ld.so.conf.d/ to make them available without copying the whole files to spotify's directory. But maybe it's not a good idea since some other program might want to use them and conflict with libav-0.9.