[MPlayer-dev-eng] Better handling of low FPS and still images

[Uoti Urpala]

On Fri, 2007-08-24 at 08:19 +0200, Reimar Döffinger wrote:
> On Fri, Aug 24, 2007 at 05:17:44AM +0300, Uoti Urpala wrote:
> > I'll probably apply them within a day or two. Of course any bugs you
> > find can still be fixed after that.
> 
> Excluding the last one I hope?

Yes, I don't intend to apply that one as is.

> Also, I had a quick look and it looks mostly okay to me (except for the
> change to bitfields, I can see quite a few disadvantages in them, but I
> haven't checked if they apply to this case), but given the

I don't think they have any real disadvantages in this case - the
resulting code should be about the same with a cleaner syntax.

> potential to completely break windows and other ports, two days is a
> much too short time unless you get someone to test.

I will wait until someone has tested it on Windows before applying
(haven't found anyone so far; I hope someone who can test on Windows
will appear on #mplayer during the day).

> Lastly, in the fallback case when HAVE_POSIX_SELECT is not available, it
> might not be a good idea to sleep the whole time, it should wake up at
> least every 100 ms and re-check if a command is available (please
> disregard if "time" can never be > 100, but even then a comment saying
> this would be nice IMO).

I have considered that and will probably add it later. I think it should
be possible implement a native Windows (is there any other supported
platform without HAVE_POSIX_SELECT?) event loop that doesn't need
polling, but that would require someone more familiar with Windows.


Is there any known platform where sleeping in select() would be less
accurately timed or otherwise disadvantageous compared to
nanosleep/usleep or other sleeping methods? MPlayer's
osdep/timer-darwin.c suggests that it might be/have been on that
platform; is that still the case and if so how significant is the
difference?