On Sat, Dec 15, 2001 at 09:42:58PM +0100, Peter Surda wrote:
> Hi guys!
>
> encoded at 23.98 or 25 fps doesn't produce smooth playback (though I think
> 29.97 does). This occurs because playback isn't synchronized to refresh, but
> to internal clock of the soundcard (actually it's more complicated, but you
> get the point).
You know that you just have to build device which
will generate vertical blank interrupt (vsyns) singal to wakeup video
renderer thread.
It's done for matrox card - but it has some problems because there
is not general lock for graphics card and several times it happend to me
that card goes into some weird mode occasinaly probably bacause control
registers are being accessed by two CPU simultaneosly (my driver and
XFree)
> So, my proposal is to add an option, that when turned on, will
> - check a special character device (mga_vid, ati_vid etc) to calculate refresh
> frequency (relative to system clock)
already done - check /dev/mga_vid opening
A.Cox announced long time ago that something like 'vsync' device will
be included into linux - but so far I can see nothing :(
(Not to mentioing even the most modern XFree4.1 is unable to play
flicker free video - something my 10 year old Amiga was doing
without any problem - oh my...)
> - calculate sound card crystal speed (relative to system clock)
> - modify soundcard frequency based on these numbers and movie fps
no way - I would not accept anything based on Sound card - we have
VIDEO player and there are videos without sound which have to be played
(we can't tell user - hey add some soundtrack to this movie :)
> - "try really hard" (TM) to maintain a fixed-frequency plaback (e.g. by using
> this special character device.
No the only real solution is to send image on the screen in VBI
(or VSYNC whatever you like more)
And until XFree developers will learn this basic elementar thing
in handling Video I do not see many options - as working with
graphics card from Linux kernel without global-lock while also
XFree sends some commands to the card isn't good thing either.
If you are now member of Xfree devel team - maybe you should finaly
urge some solution for this very necessary support.
(As myself I do not plan to build extra driver for every card - unlike
some other devel-team :) - the real fix has to be made inside XFree!!
- or maybe some other project which will replace XFree...)
> Simply telling the player "when you think you should draw, simply wait for
> refresh in addition to the stuff you usually do" doesn't solve the problem,
Yes it solves - at least for aviplayer.
Aviplay will send image to the video card - and once the image is in
video card player will wait for VBI - once the VBI arrives player send
command ty put new image on screen - of course player waits for the nearest
VBI so the images will be put on the screen like this way -
wait for #VBI 3 4 3 3 4 3 3 4 3 3 ....
note - it already works this way with matrox card.
If the Xfree would be extended even more - a lot of graphics cards could
switch buffers during VBI without any signal program programmer
(e.g. Matrox) - but there is ZERO support in XFree for this -
e.g. Xfree would have to export several buffers and allow programs to
wait for some event when buffers are full (as using timers isn't
that clean)
> because the problem isn't that it draws too soon, but too late.
the player will never draw too late if the linux kernel would be doing
proper scheduling as well - again my old Amiga was able to give
zero skip video & audio (of course not MPEG4 or MP3 - but just because
of lack of CPU power)
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- Resistance is futile. You all will be packaged
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
