Hi, as one of the GStreamer maintainers I also wanted to express my oppinion on this issue.
First of all I can only second Loic's statement that this is definitely nothing that should be changed at this stage of release before etch. The change is far too intrusive and even if it fixes h264 videos for you, Joss, I bet that there are a bunch of regressions in other parts that need special workarounds in the gstreamer plugin or just a new ffmpeg snapshot. After etch release this can be discussed again though. It's always good to reduce duplication, especially for security considerations. Also sometimes for ease of fixing bugs in only one place instead of 10000 different places. These are IMHO the only arguments that are valid for this issue. Contrary to this is, that gst-ffmpeg upstream extensively checks their current ffmpeg snapshot before release, syncs it again from ffmpeg upstream or applies workarounds for random behaviour or API changes in ffmpeg. This guarantees that the gst-ffmpeg releases work at least for great majority of files of types that are supported. If we for example choose a ffmpeg snapshot for gst-ffmpeg just before their last sync it's almost certainly that there are regressions, not only theoretical but seen in the real world. But even if our ffmpeg snapshot is newer than the bundled one with gst-ffmpeg there is a fairly high chance of regressions. Almost every time upstream syncs it's ffmpeg snapshot one can see random bugfixing and working around bugs and adjusting to completely random changes by them. I could imagine that upstream simply rejects bugs with our build with the explanation that one should try to reproduce it with a vanilla build for the above mentioned reasons. So _if_ we change gst-ffmpeg to build and link against Debian's ffmpeg _after etch release_ the following must be given: - The changes required to build with an external ffmpeg are upstream (so Joss, get your patch in a state that is acceptable by them and get it in) - Upstream, even if they don't support this change, will still look at bugreports by us and our users - We can somehow guarantee that our ffmpeg is at least as new as upstream's Bye PS: IMHO even if linking to Debian's ffmpeg saves some work for security updates this discussion definitely has wasted more time than would be necessary for a few security updates of gst-ffmpeg...
signature.asc
Description: This is a digitally signed message part
