On Tue, Jun 24, 2008 at 05:21:51PM +0300, Valery Masiutsin wrote: > > > > ports-lib-depends-check runs fine, however regression tests > > > > fail for swfdec at the moment (gstreamer with external ffmpeg > > > > issues). > > > > > > Such as? > > > > > > yes, please elaborate. I'm working on an ffmpeg update and would > > love to know potential issues to look for. > > Linking of external ffmpeg is the issue. By its nature, gstreamer > ffmpeg module has to have, reasonable defaults (bitrate, etc) for > different codecs, available in ffmpeg. > However codecs identifiers, changing in ffmpeg all the time, also new > codecs are being added, that was the reason why gstreamer folks > imported ffmpeg into the module itself. When you are linking with > external ffmpeg, you could easily hit this codec identifier mismatch. > As result you will often get errors - like > "Unknown codec ID 86022, please add here", and such. Just run make > regress in swfdec and you will see it.
this is, imo, much less of an issue than having to build another version of ffmpeg for every port that uses ffmpeg. and really, projects (especially higher profile projects like gstreamer) continuing to include their own version of ffmpeg are just perpetuating this situation. I mean, transcode for example has been using an external ffmpeg with multiple codec support for years now. yes, codecs change names now and then, but whatever, it's easy to deal with. > I am not an expert in ffmpeg and gstreamer, but this is how situation > is seen to me. > I am going to switch off gstreamer support in swfdec and turn back to > linking with ffmpeg. so, the problem is in linking gstreamer with an external ffmpeg, not just linking any app with external ffmpeg? if that's true, I'm not surprised. wouldn't be the first time I've become aware of gstreamer barfing because of arrogantly asserted untrue assumptions in it's code. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
