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

[Dan Oscarsson]

tor 2013-03-21 klockan 09:45 +0100 skrev 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 am upgrading to opensuse 12.3 om my machine. After that I will have to
re-sync all my patches to current version of mplayer. Then could be a
good time for that.

> 
> > 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?

Well, ffplay and VLC use threads. The greatest problem in mplayer is
probably all parts that fetches data between input and output parts
without any regard to multi-threading.

> 
> 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.

Xv can be made to block on vsync, if needed (at least in some X11
servers). And probably openGL too. I know at least NVIDIA sync output to
vsync. But yes, every vo have to be checked. If it does no block that is
fine, if it does part of the vo have to be in a separate thread to avoid
blocking.

> 
> 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.

vdpau do not block. But mplayer without my patches may block because it
waits for an idle surface.

   Dan