From: Steven M. S. <sms@2BSD.COM> - 2004-08-07 17:25:07
|
On Sat, 7 Aug 2004, Bernhard Praschinger wrote: > You would not use it, as far as I remember it is a Windows only SW. My allergy to windows is that obvious? :-) > lav2yuv ana.eli | yuvscaler -O VCD | mpeg2enc -f 0 -g 15 -G 15 -b 2000 > -R 2 -q 8 -4 1 -2 1 -r 8 -o xx4.m2v > Using that command, and changeing the -r value I didn't have the problem > with -r 8. I think the interaction with the -r value is a coincidence. > Could you try adding the -M 1 to you command and see if the problem > still exist ? I think that -M 1 is the default. Hmmm, but on a multi-cpu system the encoder consults the kernel for how many cpus there are and then starts that many threads _unless_ the -M option is used. > Someone with knowledge of SMP programming will be able to tell you what > really happens. Oh, I'm quite familiar with SMP programming and I know that race conditions or pthread implementation bugs are extremely hard to track down and fix... > If my observations are correct we need to track down the problem in when > mpeg2enc initalizes the default values. And look what it does when it > sets up the values when you use -M 1 and when you don't. The initialization is already done by the time the threads are started, or at least that's how the code looks to me. > I do not think the reason is the Kernel Suse uses. Because I use a > selfcompiled 2.6.7 and I also have the problem. If there's a threads problem I suspect it'll be in the area of the glibc/NPTL (New Posix Threads Library) area. The last time I did a 'generic mpeg-1' encoding was with the previous kernel+linux-threads implementation - and that worked fine. Also works with OS/X and its threading implementation so I am beginning to get the feeling there is something in the mutex handling that's different/new in the linux system(s). The problem appears to be that buffers are being processed out of order - as if a mutex acquisition is failing and allowing buffers/frames to be processed out of order. > > As a test I have a dual G5 system running OS/X 10.3.4 and ran the > So I do not need to encode it on my single CPU G4 system. It would not hurt anything to encode on a single G4 system ;) So far, single cpu systems do not exhibit the problem - which points to a problem when multiple threads are being scheduled on different cpus. This is going to be a hard problem to track down but at least a workaround (-M 0) appears to exist. Cheers, Steven Schultz |