[fritsch]

The way I see it, you're a pedantic idiot who won't let things go. This is NOT a priority and only serves to piss off everyone else. Fix the problem yourself or LEAVE. I'm fed up with people expecting hand outs and making demands as if they're owed something. This should have been a thread that ended the first page.

I had no problem using mainstream before the fix as I was able to use an up-to-date external ffmpeg were the published security bugs did no more exist. I do not run upstream code any more but fernetmenta' one except I link dynamically with the last stable ffmpeg mitigating risk and stability.

Then use xbmc as debian provides it for you and fine. Don't complain with us, complain with them - as they are obviously doing everything right. - Stone old, patche broken, but secure as hell.

[fritsch]

And to add: We are not your distribution. Everything that you build that is not in our git hub - is your personal problem - not ours. No support, just ignore list in the future.

[EricV]

So you also won't have a problem after Gotham once we move to ffmpeg mainline, right? Case closed at that point?

Main security concern will be fixed at that point yes! Just take care it does not re-happen later on! for me you need to not only move to ffmpeg mainline but set up a policy for working with ffmpeg upstream (push needed fixes upstream regularly (and for sure I know how hard it can have been), identify patches needed for XBMC if rejected by upstream for some reasons (like today for this part) so that distrib maintainer can incorporate them in their own ffmpeg packages if distribution wants to provide XBMC).

But XBMC integration into various distribution will continue to be problematic if static linking remains mandatory and the only supported way to build XBMC. This may prevent widening XBMC usage.

[jmarshall]

So exactly what FernetMenta has already done - good.

[EricV]

Then use xbmc as debian provides it for you and fine. Don't complain with us, complain with them - as they are obviously doing everything right. - Stone old, patche broken, but secure as hell.

The best secured sotware is indeed nop . No bug and noone use it!.

Be serious. During gotham development, all the possible worse choices to get a chance to get it incorporated into debian have been made and you want me to complain to them. This will immediately fires back. Static linking is a forever no go and you perfectly know it. Old version of dynamic libraries with security bugs is also a forever no go. If ffmpeg makes a come back in debian and upstream XBMC code supports fairly recent upstream ffmpeg stable releases (or even sufficiently stable unreleased git releases), things may well change. The deb-multimedia ffmpeg library just need maybe less than 5 additionnal patches to correctly run XBMC fernetmenta (mpeg2 until 2.2 is released, vc1 deinterlace, what else is in fernetmenta ffmpeg gitub for post gotahm?) meaning debian users could have packaged XBMC at almost no cost (a separated ppa like in Ubuntu).

[jmarshall]

This thread seems to have reached it's natural conclusion. No point going over and over the same stuff.

[EricV]

So exactly what FernetMenta has already done - good.

Exactly. BUT as it is indeed already ready, it thus could probably have been done on time for gotham for Linux using external ffmpeg source tree rather than forcing static linking and using old ffmpeg code. The few patches needed in ffmpeg upstream fernetmenta pushed could have been added in a specific git repository that could have been used by distribution maintainers or official Linux build until the next version 2.1 that will contains them is released. Gotham was perfectly capable of using official ffmpeg 2.1.x. once the vdpau regression fix was committed.

[negge]

The fact that XBMC works best with its own ffmpeg is one thing that can be debated, but honestly, who gives a crap about security in a library such as ffmpeg? Of all the bugs in XBMC that one is probably the one I'm least concerned about.