Zdenek,
I think you are misled about effects regarding not syncing to retrace.
There are two issues:
1. Tearing (or shearing) because you're blitting video as it's being
displayed. This is a solvable problem without creating vsync
devices. Pretty much every card supports double-buffering with the
page flip on the next retrace, and most Xv drivers do this!! Of my
i810, TNT2, and g400, both the i810 Xv driver and the nVidia
drivers page flip on retrace and never tear. The mga driver for
the g400 does not double buffer, but there is a patch which should
be applied soon which fixes this bug (see below for link).
Please, if you're seeing tearing with Xv, report it! It's probably
fixable right away in the driver.
2. Judder. This problem is beautifully described in this paper:
http://www.microsoft.com/hwdev/archive/TVBROADCAST/TempRate.asp
There are some specific problems with judder under linux. The first
is dealing with 10ms scheduling. It is important to ensure that you get
your video frames to the output in a reasonable time to amortize over
the refresh rate. I have some notes (with theoretical numbers) here:
http://www.dumbterm.net/graphics/refresh/
I achieved somewhat smoother video in my DVD player 'movietime' by
using the linux /dev/rtc device. The root user can use /dev/rtc to get
an interrupt every millisecond, and I run SCHED_FIFO to ensure
responsiveness. I make sure my blits finish right when I want them to,
and avoid being off by poor scheduling.
However, you still need to set the monitor to an appropriate refresh
rate for the video. For low framerate video this isn't so bad. That
is, for 24fps video at >=72hz and using /dev/rtc, even if you don't know
when the vtrace occurs you will almost always hit the optimal
amortization. At 60hz, things are more tricky, and for these cases
having a /dev/vsync device would help make sure you don't get screwed.
Getting accurate vsync information is _critical_ if you're playing 60fps
or 50fps material (fully deinterlaced NTSC or PAL).
> A.Cox announced long time ago that something like 'vsync' device will
> be included into linux - but so far I can see nothing :(
There is much discussion happening on this issue. Erik Walthinsen
<[EMAIL PROTECTED]> is one person who is looking into this, and I
know of at least two others. It would be great to have more people
helping out to determine what exactly is required. Right now in my
applications I use some crude code that just polls the VGA port. I
think Xpert is the best place for these discussions.
Another related issue is TV output, which badly requires vsync
information plus more (field dominance, etc). I'd like to see a
solution to both issues at once, although I'm not sure if this is
appropriate.
> 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.
As I recently found out, sending the full image during the VBI is
impossible for any reasonable frame size, and any reasonable Xv driver
double buffers. Don't knock every XFree developer just because the
matrox driver sucks.
Some links:
- I posted the patch by [EMAIL PROTECTED] here:
http://www.dumbterm.net/graphics/mga-xv-patch.txt
- Plea for help with TV output:
http://www.redhat.com/mailing-lists/video4linux-list/msg05002.html
- Thread on vsync support:
http://www.xfree86.org/pipermail/xpert/2001-October/012173.html
- Thread on tearing in mga (where I get schooled bigtime):
http://www.xfree86.org/pipermail/xpert/2001-December/013564.html
--
Billy Biggs
[EMAIL PROTECTED]
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
