Hi,

 My opinion on this matter was requested, so I'm documenting it here.
 gst-ffmpeg suffers from a very similar problem, since it has an
 embedded fork of ffmpeg.  My understanding is that upstream needs more
 than ffmpeg's offer in the first place, and also rewrote the build
 completely to be based on autotools (they told me the patch to switch
 to the autotools was rejected multiple times by ffmpeg's upstream).

 gst-ffmpeg upstream is maintaining a ffmpeg mirror, and has a complex
 procedure to update to newer snapshots.  In particular, because of the
 autotools patch, each file addition or removal needs to be added to
 Makefile.am, and, in general, each codec additions or removal needs to
 be updated in the "caps" definitions (caps is some sort of MIME type
 for a codec whichin GStreamer).

 I did try (last week!) to build gst-ffmpeg against Debian's ffmpeg
 /source/, but:
 - the process was very fragile, I had to fix the build a dozen of
   times, the patches didn't apply cleanly; I couldn't find anyway to
   improve this, upstream already uses quilt, and the problem is more in
   mapping from one build system to another
 - some semantical changes will always be required for major uploads,
   such as when codecs get added or removed from ffmpeg (gst-ffmpeg uses
   codec #defines from ffmpeg, so if you remove codecs in ffmpeg, you
   need to update gst-ffmpeg)
 - it was necessarily based on the ffmpeg *source*, and not the
   libavcodec/libavformat interfaces; would we want to base gst-ffmpeg
   build on Debian's ffmpeg, we would need a ffmpeg-src package

 I currently see no way to achieve building of gst-ffmpeg in a sane and
 maintainable way, and it seems we are very far from that.  Very very
 far.

 Nevertheless, there an upstream request to use an out of tree ffmpeg
 filed against gst-ffmpeg both in Debian and upstream.

 I don't consider the case of gst-ffmpeg to be in any way similar to
 mplayer's case; xine-lib would be closer.  Consider xine (which uses
 ffmpeg via xine-lib) or vlc, they match mplayer in functionality and do
 build directly or indirectly against libavcodec / libavformat AFAICT.

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>

Reply via email to