[MEncoder-users] Can you slow down mencoder?

Rich Felker dalias at aerifal.cx
Fri Aug 19 21:15:53 CEST 2005


On Fri, Aug 19, 2005 at 09:52:57AM -0500, Pete Davis wrote:
> > On Thu, Aug 18, 2005 at 09:45:57PM -0500, Pete Davis wrote:
> > > >
> > > > On Thu, Aug 18, 2005 at 11:08:37AM -0500, Pete Davis wrote:
> > > > > What version of mencoder are you using?
> > > > >
> > > > > I believe 1.0pre7 has problem running multiple instances of mencoder
> > > > > simultaneously. I know it was periodically causing me problems to
> > run
> > > > > multiple instances, but switching a more recent build (from CVS)
> > fixed
> > > > that.
> > > >
> > > > Huh? This is nonsense, they have no knowledge of one another..
> > > >
> > > > Rich
> > > >
> > >
> > > Rich,
> > >
> > > I'm aware the processes are isolated, but the fact remains that when
> > running
> > > 2 or more instances of mencoder 1.0pre7, it was crashing periodically.
> > It
> > 
> > This means you have a hardware problem, probably cpu overheating or
> > bad ram.
> > 
> 
> Rich, on the advice of someone here, I did run a RAM test. No problems
> found. I don't think it was CPU overheating either. I had the problem for
> several weeks while running pre7. It was fairly reliable and happened at
> least a dozen times, again, only when running 2 or more instances of
> mencoder.
> 
> 
> But again, the problem went away as soon as I upgraded and has not come back
> since. That was about a month ago. The machine is constantly running at 100%
> CPU because it runs boinc as well as doing pretty much 24 hour transcoding,
> so if it was a CPU overheating issue, surely it would have cropped up again
> by now.

No. Such issues are _random_ and will happen with some binaries, not
with others. Again, mencoder has NO CODE that's at all aware or
dependent upon other processes on the system. It will behave
identically regardless of whether it's interrupted by context switches
and how often it's interrupted, aside from the timing measurements to
estimate time to finish encoding.

Faulty hardware is very odd. It ususally only crashes under very
strange circumstances. Two processes rapidly interrupting one another
and causing context switches could very well trigger such a crash when
one running by itself does not. However, this is NOT A BUG IN THE
PROGRAM.

> > > only happened when I had 2 or more instances running and the problem
> > went
> > > away when I upgraded later out of CVS.
> > >
> > > I have no explanation for it.
> > 
> > See above. Random crash like that is ALWAYS caused by hardware
> > problems.
> > 
> 
> I've been a programmer, professionally, for about 18 years and I can say
> without a doubt that that statement is absolutely, 100% false. I'm sure
> hardware problems can be the cause of many random crashes, but certainly not
> "ALWAYS".
> 
> Any number of things can cause "apparently random" crashes like that. Bad
> pointers being one of the more common. They seem random only because we

That will not be random but deterministic.

> don't know what the exact cause is. But it wasn't terribly random. There was
> one thing that every crash had in common, and that was 2 or more instances
> of mencoder running.

This is not something in common. Something in common would be crashes
at exactly the same frame number.

> In fact, I'm tracking down a bug right now that's causing similar apparently
> random crashes (on another machine). I have absolutely no doubt that it's a
> bug in my code.

This only happens if you do stupid coding practices like threading
that make debugging impossible due to nondeterministic behavior on a
given input.

Again, I am completely positive that your crash is due to faulty
hardware or buggy OS. It is unrelated to mencoder.

Rich




More information about the MEncoder-users mailing list