[haiku-development] Re: Scheduler algorithm improvements

  • From: Izomiac <haikulist@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 9 Nov 2009 23:33:07 -0500

> > - MediaPlayer:
> > 1. media extractor thread
> > 2. event queue runner
> > 3. playback manager
>

I'll be the first to admit I lack knowledge in this area, since all I know
has been learned by things not working properly.  Back on the BeOS I had to
tweak VLC's treads quite a bit since, for me, disk reading capped out at
about 1.5 MB/sec and used quite a bit of CPU.  I noticed that I needed to
increase the priority for the disk reading thread in VLC or video playback
would suffer.

IMHO, a good way to prioritize media player threads is by what order they
process data.  So disk reading, then demuxing, then decoding, then display.
In other words, there's no work for the display if decoding isn't finished
yet; nor is there anything to decode if the demuxer isn't through yet.  Of
course, it would be better still to dynamically change priority as threads
get ahead or fall behind in their work, which should be easy to determine on
media playback.


> And make read buffers bigger.
AFAIK, read buffers ought to be somewhere around 10 - 15 seconds for local
files, probably twice or thrice that for network.  The actual number of
bytes will vary tremendously with VBR files, but it'll average somewhere
around 2 MB for TV quality, 15 MB for DVD quality and 100 MB for BluRay
quality.  That said, if there's RAM to spare then there's little reason to
not buffer a minute or two in case there's a fast motion scene ahead.

Other related posts: