Bug#395252: Same discussion concerning gst-ffmpeg
Loïc Minier wrote: > 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. > > 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. Thanks for the verbose explanation. gst-ffmpeg is indeed an exceptional case, which we'll support for Etch. (That's also why there is no RC bug on it). Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395252: Same discussion concerning gst-ffmpeg
On Thu, Nov 02, 2006 at 03:17:49PM +0100, Loïc Minier wrote: > On Thu, Nov 02, 2006, Diego Biurrun wrote: > > Just to clarify: MPlayer does not contain an embedded fork of FFmpeg, > > the FFmpeg libraries used in MPlayer are unmodified. > > I really fail to see why the same code should be in two sources then. > The Debian Mplayer packages should simply be uploaded coordinately with > ffmpeg if need be (and I don't expect that to happen too often). > > I think VLC and Xine-lib already follow this course of action, and VLC > and Xine are certainly comparable to Mplayer in terms of > functionalities and quality. The problem I see is that multiple packages in Debian use different (some forked, some not) and possibly incompatible versions of FFmpeg upstream. Forcing them all to use the same version may not be easy.. > You might still want to discuss whether Mplayer is linked statically or > dynamically with Debian's ffmpeg, i.e. weighting performances with more > rebuilds during security announces, but the presence of the ffmpeg > sources in Mplayer is not acceptable if these are pristine and Mplayer > uses the ffmpeg API. However, the FFmpeg copy in Debian is not pristine ... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395252: Same discussion concerning gst-ffmpeg
On Thu, Nov 02, 2006, Diego Biurrun wrote: > Just to clarify: MPlayer does not contain an embedded fork of FFmpeg, > the FFmpeg libraries used in MPlayer are unmodified. I really fail to see why the same code should be in two sources then. The Debian Mplayer packages should simply be uploaded coordinately with ffmpeg if need be (and I don't expect that to happen too often). I think VLC and Xine-lib already follow this course of action, and VLC and Xine are certainly comparable to Mplayer in terms of functionalities and quality. You might still want to discuss whether Mplayer is linked statically or dynamically with Debian's ffmpeg, i.e. weighting performances with more rebuilds during security announces, but the presence of the ffmpeg sources in Mplayer is not acceptable if these are pristine and Mplayer uses the ffmpeg API. > A patch was never sent, just the idea suggested. With one notable > exception the FFmpeg developers hate autotools and FFmpeg will never > replace the current build system by autotools. Hmm sorry, I didn't knew about the exact details, just that they could not push the autotools patch upstream as this had been rejected multiple times. That is, I didn't knew whether they only proposed switching to autotools or an actual patch. Thanks for clarifying, even if it does not make any difference in the end-result. -- Loïc Minier <[EMAIL PROTECTED]>
Bug#395252: Same discussion concerning gst-ffmpeg
On Wed, Nov 01, 2006 at 11:08:19AM +0100, Loïc Minier wrote: > > 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. Just to clarify: MPlayer does not contain an embedded fork of FFmpeg, the FFmpeg libraries used in MPlayer are unmodified. > 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). A patch was never sent, just the idea suggested. With one notable exception the FFmpeg developers hate autotools and FFmpeg will never replace the current build system by autotools. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395252: Same discussion concerning gst-ffmpeg
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]>
