gstreamer0.10-ffmpeg should link with system ffmpeg libraries (libavcodec, etc)

I'm not sure this is a good idea, since FFmpeg upstream is actively hostile to dynamic linking, and from the look of that bug report the gst-ffmpeg guys don't believe this is a good idea either.

If Debian do this, then we'll presumably follow them, but I don't believe that we've got the MOTU-time available to do this before Debian do.

I'm kinda curious so I'll investigate like one or two afternoons into this and post the results of whatever work I could get done. So far it looks like there's going to be a good deal of API fiddling and it's probably going to be as painful for each time ffmpeg or this package is updated.

Ok, long story short after applying above patch and doing some source-foo I got it to build against system ffmpeg in Hardy and Gutsy pbuilder and tested playback of several media types with Totem Gstreamer with great success. However, the debdiff is a bit dirty and I seek guidance/review. Yes, it's 16K lines long, most of which are due to cruft from running autoreconf recursing into the bundled ffmpeg and generating spurious changes.

Rest assured that debian/patches/24_use-system-ffmpeg.patch is nothing more than the small patch from upstream as linked in the original bug description plus a autoreconf run.

I did the API migrations in debian/patches/25_ffmpeg-api-changes.patch so that we can regenerate #24 properly with less monstrosity later on.

 So, the TODO list left is:

(1) Removal of bundled ffmpeg from sources? Should we repack the orig.tar.gz to remove the bundled ffmpeg as it's the cause of the huge debdiff and it's unnneded code.
(2) Versioned ffmpeg build-deps? I have no idea what range of ffmpegs this API will be valid for, do we need to put a versioned dep or not? Currently I left them unversioned.
(3) Additional testing? I've only tested playback of H.264+AAC, MPEG4-ASP(Xvid)+MP3 in totem-gstreamer. I don't feel satisfied with these test cases. How else can we test this package?

#1 and #2 need to be addressed before uploading this anywhere, but I think #3 can be tested in Hardy repos since we still are very early in development and there's no apparent signs of mass breakage.

WRT #3, I've tested (on Gutsy) on xvid+ac3, xvid+aac, h264+vorbis, h264+aac in mp4, and basically all I had, and it worked fine. There's probably more out there but I think I've hit the ones that aren't obscure.

I'm tired to to discuss this over and over again but having gst-ffmpeg completely working against an external ffmpeg snapshot requires more than just updating it to the new API. Take a look at the CVS history...

We are linking against the system ffmpeg since gstreamer0.10-ffmpeg 0.10.3-4ubuntu1

Clearly baltix doesn't care about this; it's probably fixed anyways.