[MPlayer-dev-eng] [PATCH][RESEND] XV page flipping sync

[Joey Parrish]

On Sun, Jun 20, 2004 at 07:26:18PM -0500, Joey Parrish wrote:
> Hello,
> 
> This mail has been sitting in my inbox for some time now.  There was no
> [PATCH] in the subject, which may be why it's not committed.

Oh, damn damn damn.  Here's the patch this time.
If there was an award for sending [PATCH] emails with no patches in
them, I think I'd be a strong contender.

> The original mail is from Piotr Neuman <sikkh at wp.pl> on Mar 14.
> 
> > On my desktop machine (Athlon XP 2000+, Gigabyte VIA VT266a, Radeon 9000, 
> > XFree 4.3, kernel 2.6.4-ck1) there were some problems in synchronization of 
> > video output (XV driver) - I could see for example 'tearing' (when double 
> > buffering was used).
> 
> > After some investigaton into it with help of Con Kolivas we were able to 
> > conclude that on my kernel/hw configuration, there is priviledge inversion 
> > issue (mplayer niced to +1 would work just fine). Such problems are usually 
> > caused by how programs are written.
> 
> > It boils down to the usage of XFlush() in libvo/vo_xv.c . The problem is that 
> > when synchronizing mplayer video buffer with X display, this function can't 
> > ensure that X server will be given timeslice soon enough.
> 
> > Mplayer can continue rendering of next frame/frames (when page flipping is 
> > used) after calling XFlush but X server may not be able to update screen on 
> > time, so few pages may be 'lost' (flipped at wrong time intervals beetween 
> > each other).
> 
> > My patch changes XFlush() call into XSync() which ensures that page will be 
> > flipped properly on time (ie. when using -double switch), becose this call 
> > waits till X has reported completion and gives free hand for system scheduler 
> > to assing timeslice for X (thanks to blocking mplayer - preempting it).
> 
> > Performance degradation is neglible, according to my limited testing. For 
> > example for Matrix mirage trailer (matrix_tr_mirage_480.mov) (sound output 
> > thru alsa1x):
> 
> > before patching:
> > BENCHMARKs: VC:  13,746s VO:   1,344s A:   0,954s Sys:  43,573s =   59,617s
> > BENCHMARK%: VC: 23,0570% VO:  2,2551% A:  1,5997% Sys: 73,0882% = 100,0000%
> 
> > after:
> > BENCHMARKs: VC:  11,691s VO:   4,802s A:   0,912s Sys:  42,216s =   59,621s
> > BENCHMARK%: VC: 19,6089% VO:  8,0539% A:  1,5296% Sys: 70,8077% = 100,0000%
> 
> > With this change the output is synchronized very well, even though mplayer 
> > uses usleep() timing (note that 2.6 kernels have clock set to 1000Hz, so 
> > using rtc is uneceseary - A-V sync is ~ +- 0,005 at worst). The issue of 
> > prority inversion is gone.
> 
> > The patch also contains removal of unneceseary calls to XFlush function just 
> > before XSync is called (XSync() alone suffices).
> 
> > Regards.
> 
> > Piotr Neuman
> 
> I can't remember if anyone responded to this, but I saw some improvement
> on my box.  But I don't know much about XV.  Any reason not to apply this?

--Joey

-- 
"Indeed do many things come to pass."
  HBT; The Book of Predictions, Chap. 19
-------------- next part --------------
From: Piotr Neuman <sikkh at wp.pl>
To: mplayer-dev-eng at mplayerhq.hu
Date: Sun, 14 Mar 2004 16:55:12 +0100
Subject: [MPlayer-dev-eng] XV page flipping synchronization
Hi, I am a newbie in mplayer delopement, so please be patient with me ;).

On my desktop machine (Athlon XP 2000+, Gigabyte VIA VT266a, Radeon 9000, 
XFree 4.3, kernel 2.6.4-ck1) there were some problems in synchronization of 
video output (XV driver) - I could see for example 'tearing' (when double 
buffering was used).

After some investigaton into it with help of Con Kolivas we were able to 
conclude that on my kernel/hw configuration, there is priviledge inversion 
issue (mplayer niced to +1 would work just fine). Such problems are usually 
caused by how programs are written.

It boils down to the usage of XFlush() in libvo/vo_xv.c . The problem is that 
when synchronizing mplayer video buffer with X display, this function can't 
ensure that X server will be given timeslice soon enough.

Mplayer can continue rendering of next frame/frames (when page flipping is 
used) after calling XFlush but X server may not be able to update screen on 
time, so few pages may be 'lost' (flipped at wrong time intervals beetween 
each other).

My patch changes XFlush() call into XSync() which ensures that page will be 
flipped properly on time (ie. when using -double switch), becose this call 
waits till X has reported completion and gives free hand for system scheduler 
to assing timeslice for X (thanks to blocking mplayer - preempting it).

Performance degradation is neglible, according to my limited testing. For 
example for Matrix mirage trailer (matrix_tr_mirage_480.mov) (sound output 
thru alsa1x):

before patching:
BENCHMARKs: VC:  13,746s VO:   1,344s A:   0,954s Sys:  43,573s =   59,617s
BENCHMARK%: VC: 23,0570% VO:  2,2551% A:  1,5997% Sys: 73,0882% = 100,0000%

after:
BENCHMARKs: VC:  11,691s VO:   4,802s A:   0,912s Sys:  42,216s =   59,621s
BENCHMARK%: VC: 19,6089% VO:  8,0539% A:  1,5296% Sys: 70,8077% = 100,0000%

With this change the output is synchronized very well, even though mplayer 
uses usleep() timing (note that 2.6 kernels have clock set to 1000Hz, so 
using rtc is uneceseary - A-V sync is ~ +- 0,005 at worst). The issue of 
prority inversion is gone.

The patch also contains removal of unneceseary calls to XFlush function just 
before XSync is called (XSync() alone suffices).

Regards.

Piotr Neuman