FFmpeg, svn:externals and where to go from here
The FFmpeg Subversion repository has been set readonly, we will not be receiving any more updates from it. The time has come to rethink the MPlayer project structure and the way we handle external libraries that we pull into our source tree. I'm undecided what to do with FFmpeg. I'd personally move towards eliminating embedded library copies, but not everybody agrees. I will rev my patches for running staged configures and reusing the FFmpeg build system more instead of duplicating it badly when I find the time. Then there is libdvdread and libdvdnav. There are many shared devs, but the project is not under our direct control and we don't know if there will be a git migration or not. libdvdread/libdvdnav sees orders of magnitude less changes than FFmpeg. IIRC (but please don't take my word for it and doublecheck) current versions are widely available in distributions now. I would suggest just dropping the svn:externals and using system versions of these libraries. The value added by the embedded copies is small, but the complication is considerable due to the ties to infrastructure of projects that are separate from MPlayer. Diego
On Sat, Jan 22, 2011 at 08:53:36PM +0100, Diego Biurrun wrote:
The FFmpeg Subversion repository has been set readonly, we will not be receiving any more updates from it. The time has come to rethink the MPlayer project structure and the way we handle external libraries that we pull into our source tree.
I'm undecided what to do with FFmpeg. I'd personally move towards eliminating embedded library copies, but not everybody agrees. I will rev my patches for running staged configures and reusing the FFmpeg build system more instead of duplicating it badly when I find the time.
Then there is libdvdread and libdvdnav. There are many shared devs, but the project is not under our direct control and we don't know if there will be a git migration or not.
libdvdread/libdvdnav sees orders of magnitude less changes than FFmpeg. IIRC (but please don't take my word for it and doublecheck) current versions are widely available in distributions now.
I would suggest just dropping the svn:externals and using system versions of these libraries. The value added by the embedded copies is small, but the complication is considerable due to the ties to infrastructure of projects that are separate from MPlayer.
I personally agree with removing them from the tree and use system one. Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it… -- Clément B.
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)? I guess 0.6 lacks some revisions that mplayer relies on. Well, we can try again with 0.7 (I'm starting to work on that), or try to get the missing revisions integrated in 0.6.2. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Latest features/bugfixes related to MPlayer development?
I guess 0.6 lacks some revisions that mplayer relies on. Well, we can try again with 0.7 (I'm starting to work on that), or try to get the missing revisions integrated in 0.6.2.
Make MPlayer depends on the FFmpeg release process is a bet I personally wouldn't risk… -- Clément B.
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Still having the MAX_STREAMS limit is. And not wanting to be kept back by having to work with ancient FFmpeg versions. Also "using the system one" all sounds nice and well, but there is not "system one" on neither Windows nor OSX, it will make compiling on these systems a _lot_ more effort. Particularly for me, and I don't see anyone else maintaining the Windows build... My suggestion would have been to stick with SVN after all unless/until we can get libdvd* as git as well at least, and hack configure to do git clone/git pull --rebase on its ffmpeg checkout. The proposed logic would be 1) check if ffmpeg/.svn exists, if yes exit and tell user to remove or replace it 2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file 3) if ffmpeg/mp_auto_pull exists, run git pull --rebase 4) otherwise do nothing, assuming the user has ser up everything manually in a way that will work. Possibly do some sanity-checking and/or print a warning.
On Sun, Jan 23, 2011 at 08:10:47PM +0100, Reimar Döffinger wrote:
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Still having the MAX_STREAMS limit is. And not wanting to be kept back by having to work with ancient FFmpeg versions. Also "using the system one" all sounds nice and well, but there is not "system one" on neither Windows nor OSX, it will make compiling on these systems a _lot_ more effort. Particularly for me, and I don't see anyone else maintaining the Windows build...
This looks no harder than compiling both MPlayer and FFmpeg to me.
My suggestion would have been to stick with SVN after all unless/until we can get libdvd* as git as well at least, and hack configure to do git clone/git pull --rebase on its ffmpeg checkout. The proposed logic would be 1) check if ffmpeg/.svn exists, if yes exit and tell user to remove or replace it 2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file 3) if ffmpeg/mp_auto_pull exists, run git pull --rebase 4) otherwise do nothing, assuming the user has ser up everything manually in a way that will work. Possibly do some sanity-checking and/or print a warning.
A build script like this is not an unreasonable idea. I've toyed with the idea myself and Uoti has implemented something similar in Python. Reports about it were very mixed, however. What about libdvdnav/libdvdread? Are you opposed to dropping them? The rate of development is much much slower than FFmpeg and changes will therefore be relatively rare. Using whatever libdvd* is installed on the system therefore looks like a sensible course of action to me. Diego
On Mon, Jan 24, 2011 at 02:55:51PM +0100, Diego Biurrun wrote:
On Sun, Jan 23, 2011 at 08:10:47PM +0100, Reimar Döffinger wrote:
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Still having the MAX_STREAMS limit is. And not wanting to be kept back by having to work with ancient FFmpeg versions. Also "using the system one" all sounds nice and well, but there is not "system one" on neither Windows nor OSX, it will make compiling on these systems a _lot_ more effort. Particularly for me, and I don't see anyone else maintaining the Windows build...
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What about libdvdnav/libdvdread? Are you opposed to dropping them? The rate of development is much much slower than FFmpeg and changes will therefore be relatively rare. Using whatever libdvd* is installed on the system therefore looks like a sensible course of action to me.
The difference is that between a simply "please try this dvdnav patch" and a ca. 50 lines instruction that still don't work on all systems (starts with the joy of /usr/local/lib not being in the library path by default). If the reason for slow development was libdvdnav being working fine that would be reasonable, but the situation is rather libdvd* being really crappy but nobody really cares so much. That is not taking into account that there generally is no system libdvdcss.
On Tue, Jan 25, 2011 at 22:32:29 (CET), Reimar Döffinger wrote:
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What's the problem with installing FFmpeg on Windows? Seriously, is there something that can done to make this step easier? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
On Wed, Jan 26, 2011 at 07:33:59AM +0100, Reinhard Tartler wrote:
On Tue, Jan 25, 2011 at 22:32:29 (CET), Reimar Döffinger wrote:
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What's the problem with installing FFmpeg on Windows? Seriously, is there something that can done to make this step easier?
Not Windows-specific really, except that there's not even the option of using a system one. The issues are - additional steps (yet another configure to run, with different options which is particularly annoying for cross-compiling) - non-trivial to start a compile of everything so you can go do something else (bigger issue on Linux actually due to make install since by default that needs root) - no reliable make uninstall - pkg-config usually does not work, so (IIRC) you manually need to convince MPlayer to find it In general just try to make a list of the steps needed if you want a user to test a patch that changes both FFmpeg and MPlayer.
On Mi, Jan 26, 2011 at 19:17:31 (CET), Reimar Döffinger wrote:
On Wed, Jan 26, 2011 at 07:33:59AM +0100, Reinhard Tartler wrote:
On Tue, Jan 25, 2011 at 22:32:29 (CET), Reimar Döffinger wrote:
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What's the problem with installing FFmpeg on Windows? Seriously, is there something that can done to make this step easier?
Not Windows-specific really, except that there's not even the option of using a system one. The issues are - additional steps (yet another configure to run, with different options which is particularly annoying for cross-compiling) - non-trivial to start a compile of everything so you can go do something else (bigger issue on Linux actually due to make install since by default that needs root)
I feel both could be solved by some scripting, which we could include in the mplayer sources
- no reliable make uninstall
only if you insist on installing to /usr/local. I personally prefer to use --prefix=~/local
- pkg-config usually does not work, so (IIRC) you manually need to convince MPlayer to find it
Well, non-standard paths require adjustment to various environment variables like PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH. But setting environment variables is also no rocket science either, rather a matter of writing that down properly.
In general just try to make a list of the steps needed if you want a user to test a patch that changes both FFmpeg and MPlayer.
agreed. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
On Wed, Jan 26, 2011 at 07:17:31PM +0100, Reimar Döffinger wrote:
On Wed, Jan 26, 2011 at 07:33:59AM +0100, Reinhard Tartler wrote:
On Tue, Jan 25, 2011 at 22:32:29 (CET), Reimar Döffinger wrote:
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What's the problem with installing FFmpeg on Windows? Seriously, is there something that can done to make this step easier?
Not Windows-specific really, except that there's not even the option of using a system one. The issues are - additional steps (yet another configure to run, with different options which is particularly annoying for cross-compiling)
I see nothing that could not be solved by a simple shell script...
- no reliable make uninstall
If you report bugs I will fix them. Diego
On Mon, Jan 31, 2011 at 10:56:12AM +0100, Diego Biurrun wrote:
On Wed, Jan 26, 2011 at 07:17:31PM +0100, Reimar Döffinger wrote:
On Wed, Jan 26, 2011 at 07:33:59AM +0100, Reinhard Tartler wrote:
On Tue, Jan 25, 2011 at 22:32:29 (CET), Reimar Döffinger wrote:
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What's the problem with installing FFmpeg on Windows? Seriously, is there something that can done to make this step easier?
Not Windows-specific really, except that there's not even the option of using a system one. The issues are - additional steps (yet another configure to run, with different options which is particularly annoying for cross-compiling)
I see nothing that could not be solved by a simple shell script...
Well, we already have one that is well tested, it's named configure.
- no reliable make uninstall
If you report bugs I will fix them.
No really ancient headers/no longer installed headers are removed (e.g. in the split subdirs), binaries from a crosscompile are not removed (i.e. only one of .so .dll .dynlib or .exe vs no .exe) library links generated by ldconfig are not removed (I have some doubts this is fixable in a sane way, and does not apply to Windows anyway I admit).
On Tue, Jan 25, 2011 at 10:32:29PM +0100, Reimar Döffinger wrote:
On Mon, Jan 24, 2011 at 02:55:51PM +0100, Diego Biurrun wrote:
On Sun, Jan 23, 2011 at 08:10:47PM +0100, Reimar Döffinger wrote:
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Still having the MAX_STREAMS limit is. And not wanting to be kept back by having to work with ancient FFmpeg versions. Also "using the system one" all sounds nice and well, but there is not "system one" on neither Windows nor OSX, it will make compiling on these systems a _lot_ more effort. Particularly for me, and I don't see anyone else maintaining the Windows build...
This looks no harder than compiling both MPlayer and FFmpeg to me.
Which is double the effort of just compiling MPlayer. However that is not counting the worst: either installing FFmpeg or beating it to be useable without installing.
What about libdvdnav/libdvdread? Are you opposed to dropping them? The rate of development is much much slower than FFmpeg and changes will therefore be relatively rare. Using whatever libdvd* is installed on the system therefore looks like a sensible course of action to me.
The difference is that between a simply "please try this dvdnav patch" and a ca. 50 lines instruction that still don't work on all systems (starts with the joy of /usr/local/lib not being in the library path by default). If the reason for slow development was libdvdnav being working fine that would be reasonable, but the situation is rather libdvd* being really crappy but nobody really cares so much. That is not taking into account that there generally is no system libdvdcss.
I still believe this can be solved by some script that fetches all components, compiles them and then builds MPlayer. Would this be sufficient for you to consider dropping libdvdread/libdvdnav? I volunteer to create something suitable in this case. Diego
On Thu, Feb 10, 2011 at 09:02:59AM +0100, Diego Biurrun wrote:
On Tue, Jan 25, 2011 at 10:32:29PM +0100, Reimar Döffinger wrote:
What about libdvdnav/libdvdread? Are you opposed to dropping them? The rate of development is much much slower than FFmpeg and changes will therefore be relatively rare. Using whatever libdvd* is installed on the system therefore looks like a sensible course of action to me.
The difference is that between a simply "please try this dvdnav patch" and a ca. 50 lines instruction that still don't work on all systems (starts with the joy of /usr/local/lib not being in the library path by default). If the reason for slow development was libdvdnav being working fine that would be reasonable, but the situation is rather libdvd* being really crappy but nobody really cares so much. That is not taking into account that there generally is no system libdvdcss.
I still believe this can be solved by some script that fetches all components, compiles them and then builds MPlayer. Would this be sufficient for you to consider dropping libdvdread/libdvdnav?
It really doesn't seem worth it to me, it's implementation effort, at least at the beginning it is almost certain to be buggy etc. If you want to spend time on getting rid of things, how about the included tremor? I just saw recently that we should be able to use the external one, and we also use the FFmpeg ogg demuxer by default, so losing our internal ogg demuxer is no longer much of an issue. Hope I am not missing something.
On Thu, Feb 10, 2011 at 09:12:51PM +0100, Reimar Döffinger wrote:
[...] It really doesn't seem worth it to me, it's implementation effort, at least at the beginning it is almost certain to be buggy etc. If you want to spend time on getting rid of things, how about the included tremor? I just saw recently that we should be able to use the external one, and we also use the FFmpeg ogg demuxer by default, so losing our internal ogg demuxer is no longer much of an issue. Hope I am not missing something.
The lavf ogg demuxer still fails on track change (new stream) while listenning to an ogg stream: try any mpd or icecast audio stream, and wait/change to the next track. -- Clément B.
On Thu, Feb 10, 2011 at 09:12:51PM +0100, Reimar Döffinger wrote:
On Thu, Feb 10, 2011 at 09:02:59AM +0100, Diego Biurrun wrote:
On Tue, Jan 25, 2011 at 10:32:29PM +0100, Reimar Döffinger wrote:
What about libdvdnav/libdvdread? Are you opposed to dropping them? The rate of development is much much slower than FFmpeg and changes will therefore be relatively rare. Using whatever libdvd* is installed on the system therefore looks like a sensible course of action to me.
The difference is that between a simply "please try this dvdnav patch" and a ca. 50 lines instruction that still don't work on all systems (starts with the joy of /usr/local/lib not being in the library path by default). If the reason for slow development was libdvdnav being working fine that would be reasonable, but the situation is rather libdvd* being really crappy but nobody really cares so much. That is not taking into account that there generally is no system libdvdcss.
I still believe this can be solved by some script that fetches all components, compiles them and then builds MPlayer. Would this be sufficient for you to consider dropping libdvdread/libdvdnav?
It really doesn't seem worth it to me, it's implementation effort, at least at the beginning it is almost certain to be buggy etc.
The implementation effort is mine, you can accept it with a clear conscience.
If you want to spend time on getting rid of things, how about the included tremor? I just saw recently that we should be able to use the external one,
What has changed, i.e. what did you see recently? I'm all for getting rid of Tremor, it's just that there used to be some tricky issues blocking it. Especially the fact that there are no Tremor releases and that the API changed. Diego
On Sun, Jan 23, 2011 at 08:10:47PM +0100, Reimar Döffinger wrote:
On Sat, Jan 22, 2011 at 11:42:02PM +0100, Reinhard Tartler wrote:
On Sat, Jan 22, 2011 at 21:16:59 (CET), Clément Bœsch wrote:
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
FFmpeg does releases these days, so what's the problem on requiring the latest FFmpeg release (0.6 at this time)?
Still having the MAX_STREAMS limit is. And not wanting to be kept back by having to work with ancient FFmpeg versions. Also "using the system one" all sounds nice and well, but there is not "system one" on neither Windows nor OSX, it will make compiling on these systems a _lot_ more effort. Particularly for me, and I don't see anyone else maintaining the Windows build... My suggestion would have been to stick with SVN after all unless/until we can get libdvd* as git as well at least, and hack configure to do git clone/git pull --rebase on its ffmpeg checkout. The proposed logic would be 1) check if ffmpeg/.svn exists, if yes exit and tell user to remove or replace it 2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file 3) if ffmpeg/mp_auto_pull exists, run git pull --rebase 4) otherwise do nothing, assuming the user has ser up everything manually in a way that will work. Possibly do some sanity-checking and/or print a warning.
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Le quartidi 4 pluviôse, an CCXIX, Reimar Döffinger a écrit :
My suggestion would have been to stick with SVN after all unless/until we can get libdvd* as git as well at least
This point could be resolved by setting up a git-svn repository, even if the upstream sticks to SVN.
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better. Regards, -- Nicolas George
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg). Index: configure =================================================================== --- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@ # ############################################################################# +if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then + rm -rf ffmpeg + echo "Failed to get a FFmpeg checkout" + exit 1 + fi + touch ffmpeg/mp_auto_pull +fi + # Prevent locale nonsense from breaking basic text processing utils export LC_ALL=C
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
Index: configure =================================================================== --- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@ # #############################################################################
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
So you choose this tree? :) I personally don't really care, but maybe you could explain very briefly your choice to mplayer developers not following the ffmpeg flames, or point out the correct ffmpeg-devel thread where you explain it. [...] -- Clément B.
On Sat, Jan 29, 2011 at 01:44:16PM +0100, Clément Bœsch wrote:
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
Index: configure =================================================================== --- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@ # #############################################################################
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
So you choose this tree? :)
I can commit to that. For now, that's the end of it.
I personally don't really care, but maybe you could explain very briefly your choice to mplayer developers not following the ffmpeg flames, or point out the correct ffmpeg-devel thread where you explain it.
What is the point? Trying to explain this objectively is an effort I prefer to avoid and I don't think it helps to direct people to flames. I'd rather explain people to use any FFmpeg tree they like (just run the clone once yourself, create a mp_auto_pull to get that feature).
On Sat, Jan 29, 2011 at 02:38:28PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:44:16PM +0100, Clément Bœsch wrote:
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
Index: configure =================================================================== --- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@ # #############################################################################
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
So you choose this tree? :)
I can commit to that. For now, that's the end of it.
I personally don't really care, but maybe you could explain very briefly your choice to mplayer developers not following the ffmpeg flames, or point out the correct ffmpeg-devel thread where you explain it.
What is the point? Trying to explain this objectively is an effort I prefer to avoid and I don't think it helps to direct people to flames.
The commit argument is a sufficient argument for me, it's all I was asking for, thanks. -- Clément B.
Reimar Döffinger <Reimar.Doeffinger <at> gmx.de> writes:
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you.
Please apply if it works for you, the current situation doesn't help. Carl Eugen
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
--- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
wrong repo ;-p Seriously though, that one resides on another server outside of our control. I once proposed converting libdvdcss into an svn:external, but you were against it, citing this very fact as an argument against an svn:external property. So are we switching libdvdcss to an svn:external now or using whatever is installed on the system? Diego
On Mon, 31 Jan 2011 10:54:56 +0100, Diego Biurrun wrote:
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
--- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
wrong repo ;-p
Seriously though, that one resides on another server outside of our
mirror git.videolan on git.ffmpeg then. -compn
On Mon, Jan 31, 2011 at 10:54:56AM +0100, Diego Biurrun wrote:
Seriously though, that one resides on another server outside of our control. I once proposed converting libdvdcss into an svn:external, but you were against it, citing this very fact as an argument against an svn:external property.
Yes, but having commit access beats having it on the same server. Also I had planned on figuring out how to best switch to a different git repository only in the long term, not just now (would probably involve detecting a mp_auto_pull repository with the old URL and refuse to continue just as before with a old SVN checkout).
So are we switching libdvdcss to an svn:external now or using whatever is installed on the system?
I fear I still might have a bit of a mplayer-specific mess in out libdvdcss that would need proper testing, review and then upstream merging at least.
On Mon, Jan 31, 2011 at 07:45:09PM +0100, Reimar Döffinger wrote:
On Mon, Jan 31, 2011 at 10:54:56AM +0100, Diego Biurrun wrote:
So are we switching libdvdcss to an svn:external now or using whatever is installed on the system?
I fear I still might have a bit of a mplayer-specific mess in out libdvdcss that would need proper testing, review and then upstream merging at least.
IIRC we still have some local changes in our libdvdcss copy. Those should be upstreamed. I already asked j-b to make you a libdvdcss committer, so this should not be a problem. Just send a patch and/or commit. If you prefer I can do it as well. Diego
On Mon, Jan 31, 2011 at 10:54:56AM +0100, Diego Biurrun wrote:
On Sat, Jan 29, 2011 at 01:30:58PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:11:31PM +0100, Reimar Döffinger wrote:
On Sat, Jan 29, 2011 at 01:09:14PM +0100, Nicolas George wrote:
Just as a reminder to myself (unless someone else implements it), step 3 should also depend on at least ffmpeg but possibly also MPlayer being at HEAD to avoid interfering with regression testing.
Some people may find it really objectionable to have ./configure start downloading things on its own accord. A separate script, and just sanity checks in ./configure, would probably be better.
Those would delete the mp_auto_pull file or just create a checkout on their own before running configure. We can ask for ok the first time.
Oh, let's stop wasting time on discussion. Here is a patch, please test it and state anything that annoys you. I'd particularly hear from distro (e.g. Gentoo) maintainers, the intention is that this should not cause issues for you if you somehow prepopulate ffmpeg/ (or just have a dummy one if you somehow can and want to compile against system ffmpeg).
--- configure (revision 32826) +++ configure (working copy) @@ -35,6 +35,29 @@
+if test -e ffmpeg/.svn ; then + echo "You have an outdated FFmpeg SVN checkout in ffmpeg/, please (re)move or replace it" + exit 1 +fi + +if test -e ffmpeg/mp_auto_pull ; then + if ! (cd ffmpeg && git pull --rebase --ff-only) ; then + echo "git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling" + exit 1 + fi +fi + +if ! test -e ffmpeg ; then + echo "No FFmpeg checkout, press enter to download one with git or CTRL+C to abort" + read tmp + if ! git clone git://git.videolan.org/ffmpeg.git ffmpeg ; then
wrong repo ;-p
no, the repo is correct. I can confirm as ffmpeg leader that the official main repository is git://git.videolan.org/ffmpeg.git Thats because a few developers have decided to take over ffmpeg.org, so the repo hosted there is just a fork by a few disgrunted devels. We are trying to negotiate with them but they pretty much refuse any compromis [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
Reimar Döffinger wrote on Sun, 23 Jan 2011 20:10:47 +0100:
2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file
As a normal user (compiling by myself, but not developing) I always found it annyoing when the downloaded source could not be compiled without some special developer tools (git in that case). The great thing about MPlayer sources until now was that it brought along everything necessary to build it. Could the nightly »normal source snapshot« please already contain a pulled ffmepg (without mp_auto_pull and .git*). I'm sure lots of normal users would be grateful. Ingo
On Mon, Jan 31, 2011 at 06:29:02PM +0100, Ingo Brückl wrote:
Reimar Döffinger wrote on Sun, 23 Jan 2011 20:10:47 +0100:
2) if ffmpeg/ does not exist, do a git clone and create a mp_auto_pull file
As a normal user (compiling by myself, but not developing) I always found it annyoing when the downloaded source could not be compiled without some special developer tools (git in that case).
The great thing about MPlayer sources until now was that it brought along everything necessary to build it.
Could the nightly »normal source snapshot« please already contain a pulled ffmepg (without mp_auto_pull and .git*). I'm sure lots of normal users would be grateful.
I agree, but I think so far not even FFmpeg itself has snapshots anymore...
Le duodi 12 pluviôse, an CCXIX, Reimar Döffinger a écrit :
I agree, but I think so far not even FFmpeg itself has snapshots anymore...
Gitweb provides snapshots: http://git.videolan.org/?p=ffmpeg.git;a=snapshot;h=HEAD;sf=tgz http://git.ffmpeg.org/?p=ffmpeg.git;a=snapshot;h=HEAD;sf=tgz
Reimar Döffinger wrote on Mon, 31 Jan 2011 19:57:18 +0100:
Could the nightly »normal source snapshot« please already contain a pulled ffmepg (without mp_auto_pull and .git*). I'm sure lots of normal users would be grateful.
I agree, but I think so far not even FFmpeg itself has snapshots
Who is the person in charge for the export script? Whom may I help extending it? Ingo
On Fri, Feb 04, 2011 at 11:11:43AM +0100, Ingo Brückl wrote:
Reimar Döffinger wrote on Mon, 31 Jan 2011 19:57:18 +0100:
Could the nightly »normal source snapshot« please already contain a pulled ffmepg (without mp_auto_pull and .git*). I'm sure lots of normal users would be grateful.
I agree, but I think so far not even FFmpeg itself has snapshots
Who is the person in charge for the export script? Whom may I help extending it?
o/ Ping me during the week, I need to update the tarball generation scripts. It's on my todo list, it's not particularly hard or anything I just need to find an uninterrupted hour to do it. Diego
Diego Biurrun wrote on Sun, 06 Feb 2011 14:12:41 +0100:
On Fri, Feb 04, 2011 at 11:11:43AM +0100, Ingo Brückl wrote:
Reimar Döffinger wrote on Mon, 31 Jan 2011 19:57:18 +0100:
Could the nightly »normal source snapshot« please already contain a pulled ffmepg (without mp_auto_pull and .git*). I'm sure lots of normal users would be grateful.
I agree, but I think so far not even FFmpeg itself has snapshots
Who is the person in charge for the export script? Whom may I help extending it?
Ping me during the week,
Ping.
On Sat, Jan 22, 2011 at 09:16:59PM +0100, Clément Bœsch wrote:
On Sat, Jan 22, 2011 at 08:53:36PM +0100, Diego Biurrun wrote:
The FFmpeg Subversion repository has been set readonly, we will not be receiving any more updates from it. The time has come to rethink the MPlayer project structure and the way we handle external libraries that we pull into our source tree.
I'm undecided what to do with FFmpeg. I'd personally move towards eliminating embedded library copies, but not everybody agrees. I will rev my patches for running staged configures and reusing the FFmpeg build system more instead of duplicating it badly when I find the time.
Then there is libdvdread and libdvdnav. There are many shared devs, but the project is not under our direct control and we don't know if there will be a git migration or not.
libdvdread/libdvdnav sees orders of magnitude less changes than FFmpeg. IIRC (but please don't take my word for it and doublecheck) current versions are widely available in distributions now.
I would suggest just dropping the svn:externals and using system versions of these libraries. The value added by the embedded copies is small, but the complication is considerable due to the ties to infrastructure of projects that are separate from MPlayer.
I personally agree with removing them from the tree and use system one.
Though, I'm not sure to understand what you plane to do for the FFmpeg repository, but using the system one will clearly lead to problems, there is too much potential different packaged versions of it…
By "system" I don't necessarily mean something that was installed by the distro package manager. Compiling your own recent libs can be a requirement if we start to rely on whatever property that will only appear in the next release of $library. Diego
participants (9)
-
Carl Eugen Hoyos -
Clément Bœsch -
compn -
Diego Biurrun -
Ingo Brückl -
Michael Niedermayer -
Nicolas George -
Reimar Döffinger -
Reinhard Tartler