[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.

[D Richard Felker III]

On Tue, Mar 19, 2002 at 11:21:23AM +1200, daniel carter wrote:
> Daniel Egger wrote:
> >Am Mon, 2002-03-18 um 01.22 schrieb daniel carter:
> >
> >
> >>>Especially for your Celeron-266 the right idea would be to make sure
> >>>that there's enough data predecoded before running into a series of
> >>>frames where the CPU really needs power to decode them so the goal
> >>>should be to equalize the load over a bigger period of time (like maybe
> >>>50-100ms) to ensure that slower CPUs have enough time to compensate
> >>>instead of dropping frames. This is exactly what you're trying with your
> >>>threads approach and it seems to work for this particular case but it's
> >>>not improving the situation in general.
> >>>
> > 
> >
> >>What would improve the situation in general then?
> >>
> >
> >As I tried to point out the optimal solution would be to decode frames
> >in advance to flatten the cpu utilisation.
> 
> A good idea indeed.  Nick has thought of this and implemented it 
> already.  In fact this thread where you make the suggestion is in reply 
> to discussion of the implementation.

There's nothing wrong with Nick's idea as a starting point. Where he's
wrong is in implying that threads are necessary or even desirable for
doing this. The same thing can be done in a much cleaner fashion
without threads, and that way you'd also avoid the cache coherency and
context switching penalties of threads, so it'd be faster too.
Unfortunately this way would also be more complicated to code, and
since (as myself and others have pointed out many times before) the
benefits of decoding ahead are quite limited, it doesn't seem
worthwhile to implement.

Rich