[EricV]

I really like open source - but thats what i hate about linux systems - every distribution can screw your app be deciding to go with the wrong versioon of a special lib.

That's the point. It's not on the packagers to decide about quality of XBMC. This decision solely is responsibility of team XBMC.

Packager decide of the quality of the code they provide in general and are very caution security wyse. Duplicating code is just a way to forget that you need to apply whatever patches to a ton of software that has the same problem, not mentioning the various incompatibilities between various software licence when you do static linking.

[fritsch]

The most secure program is the program that is never run ...

[EricV]

Those who have an issue with security and the ffmpeg version supported: just don't install XBMC
Packers who don't like internal ffmpeg: don't package xbmc

That statement makes clear that you refuse o see a brighter picture for a distro.

We only support and test against our ffmpeg fork. This is open source, those who don't like internal ffmpeg can fork XBMC and do what they think it's best for them.

As you know forking with open source is rarely a good idea. It seldom works. You are seeing the consequence of not pushing changes upstream and be forced to adapt to new releases. And yes that's exhausting.

During the past months we had quite a lot issue reports related to external ffmpeg/libav. Those team members who do Linux support have decided to kill the switch for the time being.

Was it via official distribution maintainers or just random ppa? Did you receive complains from deb-multimedia maintainer for example?

[Martijn]

Did you receive complains from deb-multimedia maintainer for example?

we get the problems that are left behind from people installing it. chasing ghost just because he doesn't use our version

[Montellese]

@EricV: IMO one point you are missing is the fact that if a packager provides XBMC with an ffmpeg version that may have better security but really bad video playback in the end the user will think

This xbmc software is crap and I'll never use it again

and maybe worse he will even tell so to all of his friends. He will certainly not think

Wow this packager of XYZ linux was an idiot, he provides xbmc with the wrong ffmpeg version

so the harm is done to the XBMC project and not to the linux distribution which screwed it up.

Furthermore most (obviously not all) users will come to us complaining about something not working, they will not go to the bug tracker of the distribution and complain there so in the end we are the ones who have to do work because someone else screwed with our work.

I'm with Memphiz on this: I really like the way you can get a library on ubuntu simply by running "apt-get install xyz" and then write the code to link to that library and use it but in the end you are always at the mercy of the distributor who might bump the version of the lib at any time and break your application. On other platforms like OSX, android and windows it takes much more effort to get those libraries ready to be linked with your software but after that there's noone who will be able to mess with that work and screw it up.

[fritsch]

Was it via official distribution maintainers or just random ppa? Did you receive complains from deb-multimedia maintainer for example?

Yes that guy was here. The official DD maintainer also was here and told the dm maintainer that his package is not official and so on, all the kindergarten at one point. And approx 27 users that complained about a non working xbmc version ... just search "debian" in the forum and you will find out. There is a point you don't get: User will come to _us_ not to their Package Maintiner that most of the time was happy after it compiled and run ...

Multiple Trac reports about "external ffmpeg" does not work for us, fix it, rewrite your software ... We have a Ubuntu ppa since several years now and a high percentage of Ubuntu users run our ppa and all is fine. At the end it's the user which wants to use xbmc, if he gets something from us, it will work. If you package the hell out of it in between - it's your problem.

[EricV]

Did you receive complains from deb-multimedia maintainer for example?

we get the problems that are left behind from people installing it. chasing ghost just because he doesn't use our version

You just close the bug as WONTFIX! Exhausting indeed!

[fritsch]

You again did not get the point. We don't fix bugs, the distributor included. If he "knows" better and ships a non supported version, we are back at the point: It's exactly his problem. PR Welcome. Open Source does not only work in one direction.

[EricV]

Was it via official distribution maintainers or just random ppa? Did you receive complains from deb-multimedia maintainer for example?

Multiple Trac reports about "external ffmpeg" does not work for us, fix it, rewrite your software ... We have a Ubuntu ppa since several years now and a high percentage of Ubuntu users run our ppa and all is fine. At the end it's the user which wants to use xbmc, if he gets something from us, it will work. If you package the hell out of it in between - it's your problem.

Again you do not get the whole picture: with you ppa you will need to provide a lot of additional packages that will either remove other software because of unssuported dependencies or break other part of the system that you do not test. So your politic is like XBMC and sorry the rest of the system!

With this type of arument, no wonder if no a lot of users helps...

[fritsch]

Don't talk wrong, if you don't know better. Have a look at the ppa: https://launchpad.net/~wsnipex/+archive/...nta-master <- realize something?

More concrete: For Saucy, you get bumped libnfs and shairplay, which can be dropped with Txyz release. And not a single other package is needed, needs to be overwritten. Nothing.

And one more hint: "Old distributions" don't get official new packages, if you need a dependency on this. The big three are not roling releases at all.

[EricV]

You lost me. You don't have numbered dependencies on mesa => may not work for amd/ati.

[EricV]

You again did not get the point. We don't fix bugs, the distributor included. If he "knows" better and ships a non supported version, we are back at the point: It's exactly his problem. PR Welcome. Open Source does not only work in one direction.

You will have to fix bugs because other have found bugs via multimedia content in ffmpeg you haven't found yet. If I had time and the way to trigger each bug explicitly, I would play the game of reporting problem linked to the ffmpeg code used by XBMC. Because you use an unsupported ffmepg version, no-one will help you.

[fritsch]

Tell me two distributions that ship ffmpeg 2.1. Just for your information:
Gentoo: http://packages.gentoo.org/package/media-video/ffmpeg
Arch: https://www.archlinux.org/packages/?name=ffmpeg

[FernetMenta]

The Mplayer devs do know as well. mplayer can only be linked dynamically to ffmpeg version 2.1.1. Means that no Linux distro provides mPlayer with external ffmpeg.

[EricV]

Tell me two distributions that ship ffmpeg 2.1. Just for your information:
Gentoo: http://packages.gentoo.org/package/media-video/ffmpeg
Arch: https://www.archlinux.org/packages/?name=ffmpeg

So what? the question is whether you can produce ffmpeg 2.1.1 for a given distro and if it can be installed alongside 1.2.x (I bet the security risk announcement may trigger some update quickly in various distro but building 150 packages takes times). As far as I know with ffmpeg dynamic library numbering its easy to have several ffmpeg libraries installation in //.