[MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.

[wm4]

On Mon, 25 Feb 2013 10:41:25 +0100
Dan Oscarsson <Dan.Oscarsson at tieto.com> wrote:

> sön 2013-02-24 klockan 21:22 +0000 skrev Vicente Sendra:
> > Any progress on this?
> 
> Sorry, I have not had time.

When will we see your patches? Can you post a preview version?

> I think you also had problem with some VO that waits until a vsync
> before returning, just like I had (and fixed in vdpau). Maybe it could
> be time to discuss if we should do some change in mplayer so that a vo
> should not hang until a vsync occurs. Both vlc and xbmc uses threads
> and works well. Why not add threads to mplayer allowing both demuxing
> and output to be in threads som more things could be done in
> parallell and idling on cpu waiting for for example a vsync could be
> avoided?

You'd probably have to lock the entire GUI to make this work in
general. Then, to avoid blocking, you'd have to marshal all accesses as
asynchronous messages, and you'd end up with an asynchronous API... But
I could see a thread-aware VO API working. Even then it's highly
questionable, because X and OpenGL often don't work very well with
threads. And how are you going to transfer the video image and OSD and
subtitles to the other thread?

To make things more fun, Xv and OpenGL don't actually block on
flip_page as far as I have observed. OpenGL often does block, but not
necessarily (only if you insert a glFinish(), or if you have a driver
that does this implicitly). So you can choose: block the CPU, or get
bad timing info.

vdpau doesn't block at all as far as I'm aware, but does return exact
timing info. OSX has DisplayLink, which allows you to do something
similar with OpenGL.