[MPlayer-users] Re: Crash report

[Rich Felker]

On Sat, Dec 24, 2005 at 11:26:01AM -0800, RC wrote:
> On Sat, 24 Dec 2005 10:29:25 -0500
> Rich Felker <dalias at aerifal.cx> wrote:
> 
> > > framedrop=yes
> > 
> > Bad. Dropping frames = nasty quality. 
> 
> The alternative being the video slowing to a crawl momentarily, when
> some background task needs the CPU.  Dropping a few frames when needed
> is just fine, IMHO (except with tfields).

It's not fine, it's incredibly ugly. And it will drop frames even when
not necessary (i.e. during fast-motion scenes where it can quickly
catch back up without dropping).

> > Also it used to cause crashing with some codecs too.. dunno if that
> > was fixed.
> 
> hardframedrop crashes libmpeg2, but I haven't seen any other crashes.

Any framedrop used to crash with h264.

> > Depends a lot on the situation, but cache will just make seeking slow
> > on media that doesn't suck (good hdd or optical drive) and will make
> > it impossible to play noninterleaved avi files. Best to enable it on a
> > per-case basis only if needed, imo.
> 
> I very often have something happen in the background that momentarily
> maxes out the hard drive, making videos freeze momentarily if not using
> cache.  With optical discs, there are often short interruptions to
> reading, due to a dirty disc, scratches, layer change, etc.  

If you have background tasks taking significant cpu time or disk io
and your cpu is slow, playing movies will suck. The question is why
are there backgroun processes using lots of (or bursty) cpu time while
you're watching a movie? Are you running updatedb or something?

> The difference in seeking is, what, 1ms?  Hardly noticable to me, and
> should be completely eliminated with the use of -cache-min 0 (though
> admitedly, that doesn't actually seem to help).

The difference in seeking is at least 1/2 second.

Rich