[fritsch]

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.

Exactly this I wanted to say.

[EricV]

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.

Again, the build process of mplayer use ffmpeg git (as told by the ffmpeg devs in a thread for a bug fernetmenta participated see https://trac.ffmpeg.org/ticket/3133#comment:62) so your point is not valid. and vlc manage to cope with external libavcodec as well. In this bug thread, may I remember you, the ffmpeg devs advised to switch to more recent version because of bugs and security fixes.

[fritsch]

What's your point? You want all millions of linux users build and install our software from source? And rebuilding every time something in ffmpeg changes?

[EricV]

What's your point? You want all millions of linux users build and install our software from source? And rebuilding every time something in ffmpeg changes?

My point is that you do not tell the complete story for mplayer and that's not fair. if the build process use fmpeg git tree and there is an autobuild system, then a packager will have up-to-date ffmpeg as soon as it update its mplayer build.

Again, my point is that using outdated ffmpeg is problematic and not supporting external ffmpeg makes it worse.

[fritsch]

You will never ever get a distribution to update their ffmpeg to another new major version during one release. That will never happen.

Reading through the trac report, you see one thing clearly. If we would have made the change, everything below 2.1 would not be working anymore. No distribution could compile us, no external ffmpeg for _every_ distribution outside would have been working anymore. No one could package our gotham release, without exactly bumping the ffmpeg packages - if they had one to this version.

This could only have been solved by "linking to an internal version of ffmpeg". If you read the bugreport a second time, you see what Fernetmenta told: FFmpeg gets updated when we branch for gotham +1.

I think your point is not at security at all. You are sitting in front of your computer and want latest / greatest and biggest and while doing so you look at a 12 fps h265 movie in full hd.

[EricV]

You will never ever get a distribution to update their ffmpeg to another new major version during one release. That will never happen.

It does for many packages including autoconf, autotools, gnutls, gcc, ...

Reading through the trac report, you see one thing clearly. If we would have made the change, everything below 2.1 would not be working anymore. No distribution could compile us, no external ffmpeg for _every_ distribution outside would have been working anymore. No one could package our gotham release, without exactly bumping the ffmpeg packages - if they had one to this version.

This again is totally false : ffmpeg devs have fixed it in 2.1git branch and ffmpeg master branch in a way that makes it compatible with untouched gotham. You are no more able to understand what you read. Cool down. What ffmpeg suggest is that as the field used are deprecated, you use another ffmpeg vdpau API that apppeared in ffmpeg 2.1. deb-mutimedia has already updated its build by applying the single fix patch and gotham is working again with ffmpeg 2.1.1

This could only have been solved by "linking to an internal version of ffmpeg". If you read the bugreport a second time, you see what Fernetmenta told: FFmpeg gets updated when we branch for gotham +1.

gotham + 1 stable is one year away. This is not a solution. My point is that for me your policy on ffmpeg is wrong and statically linking just makes it worse.

[un1versal]

Wait! The question? What question? ah so what? So what what?

@moderator, this thread does not belong in support forums, it does not ask a specific question about XBMC or Linux, it offers no logs, no bug reports for any specific problems, therefore it is a discussion, could I ask someone move it to discussions.

I have ppl to help and as a XBMC user this is both distracting and clearly OP is beyond any help,

[fritsch]

@EricV: I give up. I wish you good luck with your now working 2.1 version and hope that Gotham is out before you come back and 2.2 is released, asking us to break the old API ...

[EricV]

@fritsch @FernetMenta

As ffmpeg 2.2 (and ffmpeg 2.1.2). is probably close to be released, I'm affraid this is of no hope

On a more personal side, I like the work you (@fritsch @fernetmenta) did on amd/ATI/AE so that not because I strongly argument against ffmpeg policy that I do not prize your work and the invaluable help you provided in the past.

[fritsch]

@EricV: It's okay :-) I am a scientist, one does not need to hate eachother only cause one is of different oppinion, which happens most of the time during my research.

[un1versal]

To quote Tina Turner...

"Whats love go to do with it?"

[jjd-uk]

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.

Again, the build process of mplayer use ffmpeg git (as told by the ffmpeg devs in a thread for a bug fernetmenta participated see https://trac.ffmpeg.org/ticket/3133#comment:62) so your point is not valid. and vlc manage to cope with external libavcodec as well. In this bug thread, may I remember you, the ffmpeg devs advised to switch to more recent version because of bugs and security fixes.

The main thing I see from the ffmpeg trac ticket is that you were close to being banned from ffmpeg's trac system for not listening to the ffmpeg dev's and spamming that ticket with nonsense like you doing here and on our github.

[EricV]

Wait! The question? What question? ah so what? So what what?

@moderator, this thread does not belong in support forums, it does not ask a specific question about XBMC or Linux, it offers no logs, no bug reports for any specific problems, therefore it is a discussion, could I ask someone move it to discussions.

I have ppl to help and as a XBMC user this is both distracting and clearly OP is beyond any help,

Side comment: I used to post a comment in a pull request for forcing static linking, and some devs have bee arguing to go and continue the discussion to the forum. Then you would like me to go out of the forum. Good.

---

The main thing I see from the ffmpeg trac ticket is that you were close to being banned from ffmpeg's trac system for not listening to the ffmpeg dev's and spamming that ticket with nonsense like you doing here and on our github.

You can see it that way if you like. On the other hand, the bug has been fixed because
1) I reported it,
2) someone did the painfull work to bisect to find the commit that did really break,
3) I worked to do a reverse of the patch that did break XBMC and the risk to see it applied triggered the look by someone that did find the root cause and fixed the API break,
4) deb multimedia user have now a fully functional gotham with vdpau acceleration,


It was indeed an API break like in the original bug repor title, just ffmpeg devs were reluctant to hunt it down. I was just refusing to do all the work of hunting the bug down because API break. Besides it will help whenever you will pull a new ffmpeg version that will remove the now deprecated API.

[un1versal]

Side comment: I used to post a comment in a pull request for forcing static linking, and some devs have bee arguing to go and continue the discussion to the forum. Then you would like me to go out of the forum. Good.

1) I am not a XBMC dev, I am not part of the XBMC team, so therefore I am not aware of such request on Github.
2) They are correct Gihub is not a place for these "discussions" So yes goto forums....

However The Discussion Forums are located here XBMC General Discussion

You posted in wrong place... I merely pointed that out, these forums are Linux and Live support Since you do not have a valid support question, you have no logs, you have pointed to any bugs even if you indicate some exist, you made no such reports and therefore NOT a support topic..

So imo this should be moved there, I am not telling you to go out of the forum.... I have asked you to stop embarrassing yourself, that is more for your benefit than mine.

Please continue, but I do hope this is moved to discussions forums out of support forums.

On a related note, read my second post which is where you should have left it.

[jjd-uk]

You can see it that way if you like. On the other hand, the bug has been fixed because
1) I reported it,
2) someone did the painfull work to bisect to find the commit that did really break,
3) I worked to do a reverse of the patch that did break XBMC and the risk to see it applied triggered the look by someone that did find the root cause and fixed the API break,
4) deb multimedia user have now a fully functional gotham with vdpau acceleration,

I see it was fixed because
1) ordroid reported seeing the problem also.
2) ordroid did the work you refused to do.
3) that heleppkes isolated the issue & fixed it.

I see zero positive contribution from you.

Anyway that's me out of out here now as you're plainly not able to listen & understand what people tell you, and I've no desire to bang my head against a brick wall.