On Mon, Dec 17, 2001 at 10:12:20PM -0800, Billy Biggs wrote:
> Zdenek,
>
> I think you are misled about effects regarding not syncing to retrace.
> There are two issues:
I love to answer these emails :)
> 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).
I know that most card supports double buffering!
(e.g. it's in mga_vid for looooooong time (from XFree3.3 age - developed
by 1999 Aaron Holtzman))
> Please, if you're seeing tearing with Xv, report it! It's probably
> fixable right away in the driver.
Well just for curiosity - this problem with Matrox card was visible
from the FIRST day of the release of XFree4 - don't tell me I'm the
only one who noticed this :)
It was especially noticable with every OpenGL application (e.g. quake)
> 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:
Well I would say aviplay does a very good job at this field.
> 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
using RTC is wrong idea at the first place - requiring root user to
play smooth video with 1.5GHz processor :) - you must be joking!
(I couldn't resist - my Amiga has had just 14MHz - and video
was without tearing, sound without skips all the time)
> 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
Well I preffer different solution - I'll just note that aviplay supports
selecting VIDEO mode with desired frame refresh for playback via menu
(Of course you have to put these modes into your Xfree config file)
And when user is using refresh mode with 90Hz - you really want to wakeup
your thread when vsync signal appears and not when RTC device think
you should start blitting!!!
E.g. how it works in aviplay - there is separate thread for decoding
and separate thread for video scheduling - so there are some images
in the queue - the first one is taken and send to the Xfree - then
(with my modified mga_vid device) it will wait for vsync and
will send XSync command which will flip desired screen - there is NO better
time then this. And as the video thread is running in PERFECT sync
with VSYNC there are no propblems with this technique - except one major
problem I've mentioned in my previous post - there is missing spinlock
for access to graphic hardware so occasically I could get my card into
very strange state.
> > 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.
Well my device supports read operation - e.g. when I read device /dev/mga_vid
I'll get control back exactly in the vertical restrace time - work for 100%
as it's interrupt driven - that means it's as good as /dev/rtc
(and moreover you do not have to be root! - as this device doesn't set
anything except enabling interrupt signal on my matrox card).
Read returns 8 bytes - the first 4 are counter of interrupts - the second 4
bytes are amount of interrupts per second (e.g. 1002/81 - 1002 interrupt
and vertical refresh for the current screen is ~81Hz (this number is
integer and might change by 1 from time to time)
I would suggest you would take a look at this device and aviplayht.cpp
(it is so simple and powerfull)
Anyway if you know some list where I could subscribe myself (I've not seen
any such discussion on LKM) let me know...
> 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.
In the first place - I never use words 'sucks' - I'm just saying that
the problem is in XFree - and Xfree developers are team thus I would
say if they all KNOW that Matrox driver has problem for more then 3/4 year
which you say could be fixed within few hours I would say there is something
wrong in this team.
Now to the sending full image - it's not about sending full image !
as CPU sends memory faster then tracing ray is rendering picture n
the screen there is no problem with this - e.g.
720x576x2 (YUY2) * 100Hz requires about 82MB/s.
Moreover every card has burst mode DMA channel for such transfers
(again I do not know why it's not used with mga device).
So it's just enough when you start in VBI and if your computer operates
normaly you will never see any tearing.
Of course double buffering with page flipping is much better
as you do not have to wait for image sending - but again
- when there is no such support in XFree I could hardly use it.
(Well I could - just by using mga_vid directly :))
> - I posted the patch by [EMAIL PROTECTED] here:
thanks for interesting links
--
.''`. 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
