On Tue, Mar 25, 2003 at 09:26:35AM +0200, Ville Syrj�l� wrote: > > Well something has to be done to keep audio and video in sync.
So you were having A/V sync problems using VFCAP_TIMER that went away
when you stopped using it? I have not seen any A/V sync problems
(that were not in the original material anyway).
> I think
> mplayer tries to maintain this somehow even with VFCAP_TIMER.
I guess this is where I am at a disadvantage. I have not looked all
that deeply into what mplayer does to try to maintain A/V sync. To
me, it seems you read an audio sample from the file, see how long it
is, send it to the sound card and just be sure you come back and send
the next sample before the old one is done playing. But I am sure
there must be more to it than that.
> If I
> remember correctly I saw huge CPU usage with this flag so I think it just
> busy loops somewhere instead of sleeping. Can you confirm this?
OK. I did a handy dandy little patch to ease testing:
--- /tmp/vo_dfbmga.c 2003-03-25 09:02:40.000000000 -0500
+++ /usr/src/mplayer/p3/libvo/vo_dfbmga.c 2003-03-25 09:10:38.000000000 -0500
@@ -90,6 +90,7 @@
static int use_spic;
static int use_input;
static int field_parity;
+static int use_vfcap_timer;
static int osd_changed;
static int osd_dirty;
@@ -225,6 +226,7 @@
use_bes = 0;
use_crtc2 = 1;
use_spic = 1;
+ use_vfcap_timer = 0;
field_parity = -1;
use_input = getenv( "DISPLAY" ) ? 0 : 1;
@@ -256,6 +258,10 @@
vo_subdevice++;
}
opt_no = 0;
+ } else if (!strncmp(vo_subdevice, "vfcap_timer", 11)) {
+ use_vfcap_timer = !opt_no;
+ vo_subdevice += 11;
+ opt_no = 0;
} else if (!strncmp(vo_subdevice, "no", 2)) {
vo_subdevice += 2;
opt_no = 1;
@@ -1125,7 +1130,16 @@
return VO_TRUE;
case VOCTRL_QUERY_FORMAT:
- return query_format( *((uint32_t *) data) );
+ {
+ uint32_t flag = 0;
+
+ flag = query_format( *((uint32_t *) data) );
+ if (use_vfcap_timer)
+ flag |= VFCAP_TIMER;
+
+ return flag;
+ }
+
case VOCTRL_GET_IMAGE:
return get_image( data );
I am sure you can see, that you can use :vfcap_timer on the vo_device
arg to optionally enable VFCAP_TIMER. When I play the first 30
seconds of a given video with the flag, I get the following from
"time(1)":
13.74user 1.99system 0:32.91elapsed 47%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (3409major+3410minor)pagefaults 0swaps
and when I play without the :vfcap_timer flag, I get:
13.52user 1.65system 0:32.38elapsed 46%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (3409major+3408minor)pagefaults 0swaps
Very comparible indeed.
I am going to leave the flag enabled for some time and see if I see
A/V sync problems. I will be using a mixture of 29.97fps material and
23.98fps (de-telecined NTSC) material.
The reason I am so gung-ho on using the flag is that when I tried your
newest vo_dfbmga.c (with the triple buffering patch) I was seeing
a "periodic" (i.e. at regular intervals) judder which I am assuming
was input and output sync collisions.
Thots?
b.
--
Brian J. Murrell
pgp00000.pgp
Description: PGP signature
