Bug#482717: Latest gstreamer0.10-ffmpeg breaks gnome

[Reinhard Tartler]

retitle 482717 crashes on non-altivec machines
stop

Sebastian Dröge <slomo at circular-chaos.org> writes:

> Am Sonntag, den 01.06.2008, 16:53 +0200 schrieb Reinhard Tartler:
>> > Up to now, I was using ffmpeg from debian-multimedia.org but I tried the
>> > one from the debian archive and I get the same result.
>> >
>> > I'm not sure it is a ffmpeg bug since the problem mentions the registry.
>> 
>> Does the crash happen with 'ffplay' from the 'ffmpeg' package as well?
>
> Yes, he tested it with ffplay before I reassigned this to ffmpeg-free.

okay. so this confirms my current suspicion

>> Could you please tell me the kernel version of the machine you were
>> experiencing this? If your kernel is earlier than 2.6.17, I think I
>> know
>> what is happening here.
>
> From the gstreamer debug log he's running:
> Linux amboise 2.6.25-2-powerpc #1 Wed May 14 18:22:56 UTC 2008 ppc

That's too bad. However, I found another issue related to patch
005_runtime_cpudetect.diff. Setting RUNTIME_CPUDETECT will enable
altivec detection using the msfpr opcode, which is simulated on
non-altivec emulated machines on 2.6.17 only.

In the end I think we should disable 005_runtime_cpudetect.diff. It is 2
years old, and its purpose is to "fix" runtime cpu detection on m68k and
i386. Runtime CPU detection isn't really favored upstream, see
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-March/043886.html
and the resulting thread here.

However, a doable solution has been proposed here. lu_zero, the gentoo
ffmpeg maintainer suggested that we should install an altivec disabled
libavcodec in /usr/lib and an altivec enabled version in
/usr/lib/altivec. First very simple tests show the expected result.

Thinking further about this, we could/should do this for amd64 and i386
as well for SSE and MMX. But on the first look, this seems rather
challenging, because ffmpeg's configure does offer special configure
options for SSE3 and MMX, but glibcs runtime linker seems to check for
CMOV and for SSE2 only. I think I need better overview if it is safe to
assume that all MMX machines can be expected to support SSE2, but
currently, I don't think so.

In any case, I think I will work on reorganising the debian/rules build
target to ease building different flavors, at best in paralell. I intend
to do so to copy (using `cp -rl`) the ffmpeg source in build directories
('build/$flavor') and build there. Furthermore this leads to maintaining
a build matrix for the following flavors:

 - static
 - dynamic, noopt
 - dynamic, MMX (amd64, i386)
 - dynamic, altivec (powerpc)
 - dynamic, VIS (sparc)

and so on.

So what do you think about this plan?

>> Could you please look into this? According to debian/rules, disabling
>> altivec makes ffmpeg FTBFS. However with this bug being RC, I don't
>> see
>> how to fix the package. Since I don't have an ppc (without altivec)
>> I'm
>> not sure how to fix that.
>
> I only have PPC with altivec and there everything works fine :/

bruckner.debian.org is a powerpc machine without altivec. So testing
should be possible there.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4