[PATCH] disable mediaLib by default and make test Solaris-only
mediaLib has been broken for quite awhile now on Solaris/SPARC in lavc, and will definitely not be fixed before pre8 is released. Whenever a user encodes using lavc they get a 'thick' green-tint in the output file. A similar event takes place when decoding. mediaLib provides no performance gains for x86 -- in reality, it does the opposite. After doing some quick decoding benchmarks[1] between MPlayer binaries /w mediaLib and w/o mediaLib, I calculated that MPlayer is 2.3x faster on Solaris/x86 if one disables mediaLib, which is not the default, now. I've also made mediaLib a Solaris-only test, and updated the ChangeLog to reflect this patch. Thanks, [1] Tests done using `matrixbench_highdivx_ac3.avi' in the testsuite and lavc for decoding. -- Derek E. Lewis dlewis@solnetworks.net http://riemann.solnetworks.net/~dlewis
2006/5/12, Derek E. Lewis <dlewis@solnetworks.net>:
mediaLib has been broken for quite awhile now on Solaris/SPARC in lavc, and will definitely not be fixed before pre8 is released. Whenever a user encodes using lavc they get a 'thick' green-tint in the output file. A similar event takes place when decoding.
mediaLib provides no performance gains for x86 -- in reality, it does the opposite. After doing some quick decoding benchmarks[1] between MPlayer binaries /w mediaLib and w/o mediaLib, I calculated that MPlayer is 2.3x faster on Solaris/x86 if one disables mediaLib, which is not the default, now.
I've also made mediaLib a Solaris-only test, and updated the ChangeLog to reflect this patch.
Thanks,
[1] Tests done using `matrixbench_highdivx_ac3.avi' in the testsuite and lavc for decoding.
It is ok to disable mlib by default if it is and always have been buggy. Could you please aslo make sure that --enable-mlib would put _mlib to "auto" not to "yes". This is the convention for disabled-by-default options. However, once option is disabled by default we must assume the user knows that he is doing by explicitly enabling it again. Your way of forcefully disabling mlib on non-Solaris is not acceptable in such situation.
On Fri, May 12, 2006 at 11:41:37AM +0300, Ivan Kalvachev wrote:
Could you please aslo make sure that --enable-mlib would put _mlib to "auto" not to "yes". This is the convention for disabled-by-default options.
This is not the convention. There is no option with that behavior. (Except maybe for _dga, but it's an umbrella for several options.) Diego
2006/5/12, Diego Biurrun <diego@biurrun.de>:
On Fri, May 12, 2006 at 11:41:37AM +0300, Ivan Kalvachev wrote:
Could you please aslo make sure that --enable-mlib would put _mlib to "auto" not to "yes". This is the convention for disabled-by-default options.
This is not the convention. There is no option with that behavior. (Except maybe for _dga, but it's an umbrella for several options.)
How else the check could be executed? As for your nitpicking, the disabled by default options usually doesn't honor "yes" as force and do check anyway. In this situation it's much cleaner to set it to "auto". (so --with-mlibdir= would still skip the check).
On Fri, May 12, 2006 at 12:53:45PM +0300, Ivan Kalvachev wrote:
2006/5/12, Diego Biurrun <diego@biurrun.de>:
On Fri, May 12, 2006 at 11:41:37AM +0300, Ivan Kalvachev wrote:
Could you please aslo make sure that --enable-mlib would put _mlib to "auto" not to "yes". This is the convention for disabled-by-default options.
This is not the convention. There is no option with that behavior. (Except maybe for _dga, but it's an umbrella for several options.)
How else the check could be executed?
As for your nitpicking, the disabled by default options usually doesn't honor "yes" as force and do check anyway. In this situation it's much cleaner to set it to "auto". (so --with-mlibdir= would still skip the check).
I'm not nitpicking, you are making blatantly false statements. The disabled by default options do not do what you claim except for xvmc. Diego
On Fri, May 12, 2006 at 11:41:37AM +0300, Ivan Kalvachev wrote:
2006/5/12, Derek E. Lewis <dlewis@solnetworks.net>:
mediaLib has been broken for quite awhile now on Solaris/SPARC in lavc, and will definitely not be fixed before pre8 is released. Whenever a user encodes using lavc they get a 'thick' green-tint in the output file. A similar event takes place when decoding.
mediaLib provides no performance gains for x86 -- in reality, it does the opposite. After doing some quick decoding benchmarks[1] between MPlayer binaries /w mediaLib and w/o mediaLib, I calculated that MPlayer is 2.3x faster on Solaris/x86 if one disables mediaLib, which is not the default, now.
I've also made mediaLib a Solaris-only test, and updated the ChangeLog to reflect this patch.
It is ok to disable mlib by default if it is and always have been buggy.
However, once option is disabled by default we must assume the user knows that he is doing by explicitly enabling it again. Your way of forcefully disabling mlib on non-Solaris is not acceptable in such situation.
mediaLib (not to be confused with mlib) is Solaris-only to the best of my knowledge and a few minutes of googling support what I thought was correct in the first place. Your commit to reenable mediaLib on non-Solaris is wrong, please revert it. Diego
2006/5/12, Diego Biurrun <diego@biurrun.de>:
On Fri, May 12, 2006 at 11:41:37AM +0300, Ivan Kalvachev wrote:
2006/5/12, Derek E. Lewis <dlewis@solnetworks.net>:
mediaLib has been broken for quite awhile now on Solaris/SPARC in lavc, and will definitely not be fixed before pre8 is released. Whenever a user encodes using lavc they get a 'thick' green-tint in the output file. A similar event takes place when decoding.
mediaLib provides no performance gains for x86 -- in reality, it does the opposite. After doing some quick decoding benchmarks[1] between MPlayer binaries /w mediaLib and w/o mediaLib, I calculated that MPlayer is 2.3x faster on Solaris/x86 if one disables mediaLib, which is not the default, now.
I've also made mediaLib a Solaris-only test, and updated the ChangeLog to reflect this patch.
It is ok to disable mlib by default if it is and always have been buggy.
However, once option is disabled by default we must assume the user knows that he is doing by explicitly enabling it again. Your way of forcefully disabling mlib on non-Solaris is not acceptable in such situation.
mediaLib (not to be confused with mlib) is Solaris-only to the best of my knowledge and a few minutes of googling support what I thought was correct in the first place.
Your commit to reenable mediaLib on non-Solaris is wrong, please revert it.
I've used and tested the solaris x86 mediaLib on slackware with additional solaris libc package, so it is not impossible. As Derek says, it is not optimized and slower. I'm not going to revert it, because i just restored the old behaviour. And in case you are ready to show muscles, this wasn't the right way to disable it.
On Fri, 2006-05-12 at 06:40, Ivan Kalvachev wrote:
I've used and tested the solaris x86 mediaLib on slackware with additional solaris libc package, so it is not impossible. As Derek says, it is not optimized and slower.
Yes, it is *much* slower on x86.
I'm not going to revert it, because i just restored the old behaviour. And in case you are ready to show muscles, this wasn't the right way to disable it.
I don't understand what's wrong with the way its been disabled. If the user wishes to enable (obviously, for some stupid reason) it, they can specify --enable-mlib and it'll force it to be enabled. This is way things are and should be in 'configure'. By default, it should be disabled as it adds no benefits for SPARC *or* x86. Thanks, -- Derek E. Lewis dlewis@solnetworks.net http://riemann.solnetworks.net/~dlewis
2006/5/12, Derek E. Lewis <dlewis@solnetworks.net>:
I don't understand what's wrong with the way its been disabled. If the user wishes to enable (obviously, for some stupid reason) it, they can specify --enable-mlib and it'll force it to be enabled. This is way things are and should be in 'configure'. By default, it should be disabled as it adds no benefits for SPARC *or* x86.
Your way of disabling also skips the "--disable-mlib" path and skips the inclusion of "#undef HAVE_MLIB" in config.h. The question why we need undef is completely different topic ;) The right way to disable it would be something like + if ! sunos ; then + _mlib=no + fi echocheck "Sun mediaLib" if test "$_mlib" = auto ; then (copyrighted, don't use in configure;)
On Fri, 2006-05-12 at 07:21, Ivan Kalvachev wrote:
The right way to disable it would be something like
Ah, you are correct in this instance. Fair enough, let me provide another patch. Thanks, -- Derek E. Lewis dlewis@solnetworks.net http://riemann.solnetworks.net/~dlewis
Oops. Here's another patch to update the output of './configure --help', so that it reflects the ChangeLog and the previous 'configure' patch. Thanks, -- Derek E. Lewis dlewis@solnetworks.net http://riemann.solnetworks.net/~dlewis
OK, here's the latest revision that combines my previous patch to update the output of './configure --help' and a patch that addresses that Ivan's observations. Kudos to Ivan for his observations and his suggestion (minus the blatant Bash-ism). :-) Thanks, -- Derek E. Lewis dlewis@solnetworks.net http://riemann.solnetworks.net/~dlewis
Hi! This is a very old mail, but I only tested this now. Friday 12 May 2006 02:19-kor Derek E. Lewis ezt írta:
mediaLib has been broken for quite awhile now on Solaris/SPARC in lavc, and will definitely not be fixed before pre8 is released. Whenever a user encodes using lavc they get a 'thick' green-tint in the output file. A similar event takes place when decoding.
I don't see a green tint when using the mediaLib idct in ffmpeg on SPARC. In fact it works fine. So how can one reproduce this problem? It seems the idct is fine with mediaLib 2.4. I also tried the mlib yuv2rgb, and it seems red and blue is inverted. So there seems to be a problem there indeed. But no thick green-tint whatsoever. bye Denes -- --- What kills me, doesn't make me stronger.
On Thursday 12 July 2007 22:22, Balatoni Denes wrote:
I don't see a green tint when using the mediaLib idct in ffmpeg on SPARC. In fact it works fine. So how can one reproduce this problem? It seems the idct is fine with mediaLib 2.4.
I tested playback of mpeg4/xvid with and without medialib a few weeks ago. medialib enabled on sparc was faster than without medialib, and there was no green tint for me either.
I also tried the mlib yuv2rgb, and it seems red and blue is inverted. So there seems to be a problem there indeed. But no thick green-tint whatsoever.
I get the r<->b swap even without mlib.
participants (5)
-
Balatoni Denes -
Derek E. Lewis -
Diego Biurrun -
Ivan Kalvachev -
Jan Knutar