[MPlayer-users] Fresh svn mplayer crashes on many ac3 streams

Ivan Kalvachev ikalvachev at gmail.com
Sun May 29 03:24:35 CEST 2011


On 5/29/11, Vladimir Mosgalin <mosgalin at vm10124.spb.edu> wrote:
> Hi Reimar Döffinger!
>
>  On 2011.05.28 at 22:14:58 +0200, Reimar Döffinger wrote next:
>
>> > The thing is, you see, this is default mode; on sandy bridge systems
>> > "-march=native" with gcc 4.6 or higher
>>
>> Huh? 4.6.0 is the latest version.
>> And honestly, the answer is: you never, never ever use a .0 version of gcc
>> for stuff you actually use.
>> To my knowledge there hasn't been a single one without serious issues and
>> MPlayer most of the time is affected.
>> Slightly more useful: -fno-tree-vectorize probably should always be used
>> as for FFmpeg, the only thing it does is make the code slower and cause
>> bugs.
>
> But it's latest stable version. Plus it's the only compiler in current
> stable fedora release.
>
> Anyhow it's a bit unfair to blame it on ".0" here, I think, since this
> issue is related to avx as well and 4.6.0 was first stable release to
> include avx support. It's, like, not gccs fault that avx support
> appeared in .0 version and not some other..
> (plus, we don't yet known if it's gcc problem or actual bug in ac3dec.c
> code..)

This is phenomenon we have observed since 3.0.0 onward.
(Actually gcc-2.96.0 was the worse compiler ever to compile linux.
However it was not official release. It was just gcc3 ported back by
RedHat in a very bad way. )


> I can turn off avx or ftree-vectorize, it's np to me - though I expected
> some serious speedups from gcc 4.6.0 and avx support, like shown in some
> phoronix benchmarks, for example
> http://www.phoronix.com/data/img/results/intel_avx_gcc/6.png
> http://www.phoronix.com/data/img/results/intel_avx_gcc/7.png

All speed critical parts of codecs are separated and assembly
functions are written to use the SIMD available on the CPU. In that
sense you are not going to get significant speedup from the automatic
SIMD. That is if it produced optimal code.

Of course, AVX optimizations are still in process of writing.

> but I guess the real issue here is that ffmpeg's configure isn't
> executed so ffmpeg's will to add -fno-tree-vectorize flag is ignored?

The vectorize may break code and in other parts of MPlayer, so better
be safe and use it everywhere.


More information about the MPlayer-users mailing list