On Sat, 28 Nov 2009 10:25:13 +0100 >>>>>> "Francesco" == Francesco Romani <from...@gmail.com> wrote:
Francesco> the rgb24 internal format should'nt be used if the source
Francesco> material is already in yuv420 colorspace because doing the
Francesco> conversion is slower and (slightly) degrades the quality,
Francesco> that's the only reason.
I'm told it's slower, wasn't sure about degrading the quality.
Francesco> > > cmove asm decode_mpeg2.c libmpeg2 acceleration: mmxext
Francesco> > > /usr/bin/dvdcpics: line 263: 17694 Segmentation
Francesco> > > fault ...
Francesco> > transcode wants to use mmxext instruction set while my cpu
Francesco> > (i7 860) does not provide it
Francesco>
Francesco> More precisely, libmpeg2 wants to.
Francesco> If that's the root of the problem, then it's a libmpeg2
Francesco> problem and there is little than we (as transcode team) we
Francesco> can do.
Hmm, I was looking at libmpeg2's configure, but didn't see any option
to enable/disable mmxext set. :-(
Francesco> However. I must admit than I know the i7 cpus only by
Francesco> reading docs, but I'm an hardware junkie and so I'm pretty
Francesco> confident that your cpu provides such instructions.
Heh, see below:
[g...@gaura-nitai gour] cat /proc/cpuinfo | grep flags flags: fpu vme
de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable
nonstop_tsc pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr
pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept
vpid
Francesco> `mmxext' is deep jargon (mostly found on linux field AFAIK)
Francesco> for some MMX extended instructions that aren't explicitly
Francesco> advertised; I can't recall the exact details but those were
Francesco> added together with the first round of SSE or something like
Francesco> that.
I also do not have any knowledge about it.
Francesco> So, unless I missing something huge, the core i7 definitley
Francesco> support them :)
Is cpuingo lying then?
Francesco> Uhm, looks like an unconventional choice of flags to me;
Well, I've followed distro's default and bumping to 1.1.5.
Francesco> However, as written above, the libmpeg2 asm acceleration is
Francesco> mostly out of control of transcode.
OK.
So
> cmove asm decode_mpeg2.c libmpeg2 acceleration: mmxext
means that libmpeg2 is wrongly detecting accelaration capabilities.
By inspecting libmpeg2's sources, I've found the following:
#if defined(ARCH_X86) || defined(ARCH_X86_64)
static inline uint32_t arch_accel (uint32_t accel)
{
if (accel & (MPEG2_ACCEL_X86_3DNOW | MPEG2_ACCEL_X86_MMXEXT))
accel |= MPEG2_ACCEL_X86_MMX;
if (accel & (MPEG2_ACCEL_X86_SSE2 | MPEG2_ACCEL_X86_SSE3))
accel |= MPEG2_ACCEL_X86_MMXEXT;
if (accel & (MPEG2_ACCEL_X86_SSE3))
accel |= MPEG2_ACCEL_X86_SSE2;
and it looks that the above code is wrong assuming, if I'm correct,
that MPEG2_ACCEL_X86_SSE2 | MPEG2_ACCEL_X86_SSE3 means there are
MMXEXT available, right?
Francesco> > I've tried to set --accel C, but it does not help.
Francesco> > Any hint?
Francesco>
Francesco> Recompile libmpeg2.
I already did it, but it crashes.
Francesco> The other (and independent) way to go is patching the
Francesco> transcode's mpeg2 import module.
Don't know what it would involve, but I'll inform libmpeg2 crew.
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: F96FF5F6
----------------------------------------------------------------
signature.asc
Description: PGP signature
