Re: [Mjpeg-developer] mpeg2enc -f 0 (generic MPEG-1) with -R 2

[Steven M. S. <sms@2BSD.COM>]

On Sun, 8 Aug 2004, Bernhard Praschinger wrote:

> By now we know that it seems to happen on Linux Athlon SMP Systems with
> Suse 9.1 If you use a -r >8 and -R = 2.

	And does not happen on OS/X with _any_ combination of -M or -r even
	on a dual cpu system.

	That is what leads me to suspect there could be a pthreads issue 
	in glibc's implementation of pthreads or a subtle bug in mpeg2enc
	that is interacting badly with the new threads library in recent
	linux systems.

> And from what I remember some compilers initialize variables with a
> default value of 0, and some don't care about that. I think that could
> hit use here. 

	Actually, I tought the ANSI C standards specified that (global or
	static) variables were required to be initialized to 0.

> When the stream is "broken" in mplayer (dev-CVS-040625-06:00-3.3.3). I
> also see the same in xine 0.9.23 and vlc 0.7.2. Mplayer does not break up.

	Ah, ok - I must have lost track of which system I was playing the clip
	on.  I know that the latest cvs version of MPlayer does not work on
	OS/X for MPEG-1/2.

> >         mpeg2enc -M 2 -f 0 -b 1000 -R 2 -q 8 -r 16 -4 1 -2 1 -o xxx.m1v
> > 
> > -M 0: MD5 (xxx.m1v) = bb2271ba290a431987f5df1cebdb3697
> > -M 1: MD5 (xxx.m1v) = 5232942c2a907f85f028eba04c3710e2
> > -M 2: MD5 (xxx.m1v) = 4b8a3c14f22eb5bbecd3f3957e90701d
>
> Did you specify the -M 1 or not ?

	Yes, I had an explicit -M and varied the numeric argument.

> >    If a .m1v file is generated with "-M 0" shouldn't it be the same as the
> >   .m1v file generated with a higher number of threads such as "-M 2"?

> I always thought so.

	Ok, then there's definitely a bug present.  The number of worker
	threads used causes the output to be different.

> When I run it now with 1000 frames and your command I get:
> Option             Output           MD5sum:
> -M 0:              Using 0 threads, 3ac8f3238604d1e6a6438e783b158d85
> -M 1:              Using 1 threads, 3ac8f3238604d1e6a6438e783b158d85
> -M 2:              Using 2 threads, ce3a878f446c8048c63e77d8102a5fab
> -M 4:              Using 4 threads, a0a3266a75c5b0d4f2120ffdbce1e632
> without adding -M: Using 2 threads, 8b61be132d5c0c93193cd4d1391e6f7a


	Amazing!  Using "-M 2" on a dual cpu system gives different results
	than using 'sysconf(_SC_NPROCESSORS_ONLN)' (which is 2)!

> But I think I found out, mpeg2enc seem to get information from:
> _SC_NPROCESSORS_ONLN, and changes the default number of threads it uses

	Right, and I do not think that is a good idea.  Doing that gives
	a silent change in behaviour depending if you happen to be on a 
	single or multi-cpu system

	The other thing that does not seem right is that the 'max_cpus' is
	limited to 32 but the MAX_WORKER_THREADS is limited to 4.   Since
	there is no benefit with more than 2 or 3 threads I could see limiting
	the max value of -M to 4.  Besides, how many of us can afford 8-cpu
	systems? :)

	I could see the default being -M 1 (to use the I/O thread) but
	anything higher than "-M 1" should be by explicit request of the
	user.

	What do others think?   Any objections to revising the num_cpus/threads
	handling to require the user to use -M > 1 for SMP systems?

> So Dual CPU machines use by default 2 encoding threads instead of one in
> Single CPU Machines.

	Right - so if you are doing comparison testing on different systems 
	you'll get different results even if you are using the same command 
	line!

> The deeper I dig the more confused am I. 

	Me too.

> It would be very interresting to have result from a Dual CPU Machine
> with another linux.

	Ah, good idea!  The Fedora Core-3 Test1 images are available - I will
	burn a copy of that at work tomorrow and bring it home.

> Using -M 2 on my single CPU G4 MAC I also have the same problem I have
> on my Dual CPU Athlon. So at least on my systems it is related to what

	Hmmm, on the dual G5 MAC I have no problems at all (except for MPlayer
	crashing on MPEG-1 or -2).

	Cheers,
	Steven Schultz