[EricV]

Compiling was not the problem. Execution was due to a subtle API breakage for VDPAU. The bug is now fixed in ffmpeg https://ffmpeg.org/trac/ffmpeg/ticket/3133 BUT the proper fix would be for XBMC to use a new ffmpeg 2.1 API and fernetmenta already knows about it.

Don't overestimate yourself in that game. Telling devs what they should do is definitely not your job. And in the same moment mentioning a software version that absolutely no one of the big three distributions has in its repositories ...

I know the rule with open source: you are given the credit based on your skills and effective contribution. Mines are indded low for XBMC. Given my graphical video programming habilities, I did not even tried argue about technical details for this partcicular bug.

On the other hand do not underestimate my experience about having to deal with open source software embedded on hardware used by several million people and the cost of using obsolete, buggy open source package.

[fritsch]

On the other hand do not underestimate my experience about having to deal with open source software embedded on hardware used by several million people and the cost of using obsolete, buggy open source package.

Won't do. You 're welcome.

[EricV]

[
link http://http//ffmpeg.org/security.html goes nowhere of consequence it has double http:. You meant to link to http://ffmpeg.org/security.html but ok everyone makes mistakes...
link http://http//trac.xbmc.org/ticket/14838 again double http its now obvious you are even unable to copy and paste, never mind make a valid argument.

Just on this : when you click URL, it open a pop up with "http://" selected. I wrongly assumed pasting will erase the fisrt http:// but indeed did not check. Obviously it does not.

[un1versal]

Stop embarrassing yourself... Please!

[EricV]

The cost of upgrading ffmpeg is very, very heavy. We are multi-plaform. Arm asm can get every tricky on Android/iOS and those platforms are hardly ever 'tested' by FFMpeg gods. The last version bump was painless, the one before that killed iOS platforms with changes in asm/linker code. It took a year to get someone interested in understanding and fixing the issue.

Sure the ARM ABI change for armhf, the various floating point (neon other, ..) and the IOS/Android environment stuff with their proprietary API, libc multimedia framework must be a nightmare.

We don't like external ffmpeg, it gets abused and distros don't take the time or do not understand that as a mediacenter we are ver, very sensitive to FFMpeg changes. They toss the most recent version at it, fix compile issues and presto... We run like crap and users flock into the forums complaining.

Usually when officially packaged, bugs for a program should be handled by maintainer first. If he makes wrong decision, then he will have to assume them. I dunno how it works for official debian but they only propose 12.3 using external libav. For deb-multimedia, gotham alpha are proposed with ffmpeg 2.1.1 external. I think youre seeing problem on the forums, on the contrary, because XBMC is either not officially packaged by distributions or has been only very recently.

So, if you want something that works, use our internal FFMpeg. If you want something that is secure but cannot reliably play audio/video content, use external FFMpeg or Libav.

I have been running external ffmpeg for at least two years. My experience is that it works at least as good as internal version ON LINUX. I did pay the price on some occassion.

EDIT:
Besides, it's just plain way too late in our current release cycle to bump FFMpeg. We would have to start from scratch again and add 2-3 months for stability testing.

You're the devs. I suspect distributions will have to evaluate the security risks and should continue to be offered the external alternative. The fact that CVE for ffmpeg have been disclosed publicly just make things worse from a security point of view.

[teeedubb]

Don't tell anyone but the xbmc foundation is actually a splinter cell of the NSA and they want this CVE in xbmc so they can pilfer your custom key maps, plugin settings and incorrectly scanned content.

[un1versal]

Don't tell anyone but the xbmc foundation is actually a splinter cell of the NSA and they want this CVE in xbmc so they can pilfer your custom key maps, plugin settings and incorrectly scanned content.

Google is a NSA front who gather intelligence including to also various others Government agencies which are dark classified G14, Facebook also very much a CIA front to gather data on Threats to the national security OF USA.

They all Conspired to have XBMC source code injected with several backdoors so the could access ffmpeg security flaws, everytime a user is eating toast. The are after Libraries, a unresolved bugs which date back to 3 to 4 years + and no developer will touch the code, because that's where the backdoors are.

The Black Helicopters are often up around here, for hours gathering information o what I type here and what replies I get., sometimes I hear giggles...

[davilla]

and now we will have to k**l you

[un1versal]

@ OP
These are 9 of the 17 security issue patches.

https://github.com/FFmpeg/FFmpeg/commit/...759c66f91f
https://github.com/FFmpeg/FFmpeg/commit/...32f4753f34
https://github.com/FFmpeg/FFmpeg/commit/...3453299760
https://github.com/FFmpeg/FFmpeg/commit/...dab7e33445
https://github.com/FFmpeg/FFmpeg/commit/...3be2b8ca4a
https://github.com/FFmpeg/FFmpeg/commit/...c860554ce0
https://github.com/FFmpeg/FFmpeg/commit/...1c0fe0bb07
https://github.com/FFmpeg/FFmpeg/commit/...5683309446
https://github.com/FFmpeg/FFmpeg/commit/...a76e6e2d8f

Start working.

and now we will have to k**l you

Ah please, come and put yourself out of my misery.

[teeedubb]

and now we will have to k**l you

Haha

*teeedubb looks at his htpc suspiciously...

[un1versal]

@teeedubb

Its not the HTPC you have to worry about, its likely your toaster... Think misdirection!

* un1versal throws any portable electrical devices out the window...

[EricV]

So, if you want something that works, use our internal FFMpeg. If you want something that is secure but cannot reliably play audio/video content, use external FFMpeg or Libav.

As a matter of fact, there is currently a pull request that will force static linking for ffmpeg (and many other libs by side effects) 4005 (PR). The rationale of doing this is said to force a given ffmpeg library version upon packager. There is even the expressed opinion that packager opinion does not matter!

Pushing that type of arguments would also request x264, mesa, kernel itself. For amd/ati, nouveau and the new hardware video decoding feature relying on vdpau in mesa and kernel DRM code, I bet you will have at least as much problem with mesa/kernel comination than with ffmpeg.

I really think this will prevent any packaging.

[FernetMenta]

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

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.

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.

[Memphiz]

Letsview it from a different angle.

This is not about opinions. Wedid it the packager way (external ffmpeg) for years now and the support burned out a lot of people (extremness intended). No we just try out the other approach which is done on all other platforms since i can think back (we decide which version of ffmpeg is used) - and really - as a osx and ios maintainer of xbmc i had never any ffmpeg "wrong version" related support stuff to worry about.

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.

So just take it as trial and error - if nothing works in gotham - we can still can go back to the external approach again. And please don't argue now that when that happens we will have lost all packager support. If so - not our problem - distribution userbase has to pester them to do the right thing in that case. You can't just put all strange distribution issues in our hands - for that the count of active developers on xbmc is way way to low.

[FernetMenta]

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.